Bug 796059

Summary:	Polkit switched from .pkla to .rules
Product:	[openSUSE] openSUSE 12.3	Reporter:	Michael Catanzaro <mcatanzaro>
Component:	Basesystem	Assignee:	Ludwig Nussel <lnussel>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P2 - High	CC:	dimstar, gp, lnussel, meissner
Version:	RC 1
Target Milestone:	RC 2
Hardware:	x86-64
OS:	SUSE Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	tz settings disabled

Description Michael Catanzaro 2012-12-28 02:45:20 UTC

User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.6+ (KHTML, like Gecko) Chromium/17.0.963.56 Chrome/17.0.963.56 Safari/537.6+ SUSE/12.3 (3.6.1) Epiphany/3.6.1

It is no longer possible to change the timezone in GNOME Control Center without unlocking the module with an admin password. (12.3 Milestone 2)

Reproducible: Always

Steps to Reproduce:
1. Open Date and Time settings.
2. Don't unlock the module.
3. Observe that timezone settings are locked.
Actual Results:  
Timezone settings should be available for unprivileged users.

Expected Results:  
Timezone settings are locked.

gnome-control-center-fine-grained-tz-polkit.patch applies cleanly but clearly no longer works. I have not yet investigated further.

Comment 1 Michael Catanzaro 2012-12-28 02:46:15 UTC

Created attachment 518428 [details]
tz settings disabled

Comment 2 Michael Catanzaro 2013-02-19 15:59:05 UTC

In /etc/polkit-default-privs.standard I have:

org.freedesktop.timedate1.set-timezone auth_admin_keep:auth_admin_keep:yes

which is the same as the setting I had in 12.2. But the timezone options are greyed out.

But in 12.3, if I decide to be bad and manually edit the default permission in /usr/share/polkit-1/actions/org.freedesktop.timedate1.policy, the timezone settings become accessible. O_O So I'm very confused.

Perhaps our authorizations in polkit-default-privs.standard are not being evaluated?

Comment 3 Dominique Leuenberger 2013-02-19 16:04:32 UTC

They are evaluated, but there is a slight difference:

- our policy only grants set-timezone  and the .policy file gives full access over the entire panel (incl. changing the 'actual' time).

Surprisingly, though, the 'unlocking' of the panel seems to rely on a much higher privilege than before (the map is not being unlocked anymore in case the user has the set-timeszone privilege).

(not sure about 'normal' vs. 'minor'.. could as well be 'enhancement' :P )

Comment 4 Michael Catanzaro 2013-02-20 21:19:54 UTC

(In reply to comment #3)
> Surprisingly, though, the 'unlocking' of the panel seems to rely on a much
> higher privilege than before (the map is not being unlocked anymore in case the
> user has the set-timeszone privilege).

Actually the code has not changed at all since GNOME 3.4, our default-privs have not changed since GNOME 3.4, and the systemd default policy has not changed... so I really just don't understand why it has stopped working.

But it's somewhat a moot point for now -- I am creating an SR with this patch disabled due to Bug #796055 (unlike timedate1, gnome-settings-daemon does not provide a timezone subpermission that we can use).

Comment 5 Marcus Meissner 2013-02-20 21:42:32 UTC

I hacve the slight suspicion that polkit-default-privs might have stopped working

i received one other report also sounding like that.

Comment 6 Marcus Meissner 2013-02-20 21:45:21 UTC

polkit packs 
/var/lib/polkit/

while polkit-default-privs packs
/var/lib/polkit-1/

... suspicipus

Comment 7 Marcus Meissner 2013-02-20 21:49:14 UTC

well ... yes ... 
- Changes from version 0.106:
  + Major change: switch from .pkla files (keyfile-format) to
    .rules files (JavaScript)
  + Nuke polkitbackend library, localauthority backend and
    extension system

fscking fsck.

Comment 8 Michael Catanzaro 2013-02-20 23:08:30 UTC

I updated the bug's metadata as "Enhancement - Low Priority" no longer seems quite appropriate... please correct as you see fit.

Comment 9 Michael Catanzaro 2013-02-26 16:00:44 UTC

Seems to be fixed in Factory, yay.

*** This bug has been marked as a duplicate of bug 804376 ***