Bug 1153725
| Summary: | gnome-control-center - Date and time does not respect polkit | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Oliver Ilian <oliver> | ||||
| Component: | control-center | Assignee: | Bastien Nocera <bnocera> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.0 | CC: | oliver | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-03-31 12:25:56 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Oliver Ilian
2014-10-16 16:13:45 UTC
There's no attached file. Created attachment 947856 [details]
polkit rule to allow users to change timezone
gnome-control-center does respect polkit. In fact, it installs a /usr/share/polkit-1/actions/org.gnome.controlcenter.datetime.policy file to allow authorising all of those actions in a single query:
<annotate key="org.freedesktop.policykit.imply">org.freedesktop.timedate1.set-time org.freedesktop.timedate1.set-timezone org.freedesktop.timedate1.set-local-rtc org.freedesktop.timedate1.set-ntp</annotate>
If that's not overridable, then it's a problem in polkit.
Your polkit file is unlikely to be sufficient in any case, as you would need to deny the authorisation for the other actions, and by authorising org.gnome.controlcenter.datetime.configure, you automatically grant authorisation to all the actions listed above.
(In reply to Bastien Nocera from comment #4) > gnome-control-center does respect polkit. In fact, it installs a > /usr/share/polkit-1/actions/org.gnome.controlcenter.datetime.policy file to > allow authorising all of those actions in a single query: > <annotate > key="org.freedesktop.policykit.imply">org.freedesktop.timedate1.set-time > org.freedesktop.timedate1.set-timezone > org.freedesktop.timedate1.set-local-rtc > org.freedesktop.timedate1.set-ntp</annotate> > > If that's not overridable, then it's a problem in polkit. > > Your polkit file is unlikely to be sufficient in any case, as you would need > to deny the authorisation for the other actions, o.f.policykit.imply is not supposed to be an end-user overridable item; it is a matter of permission system design, and applications that set up the .imply annotation have an IMHO legitimate expectation that when the implying action is allowed then the implied actions are allowed as well (the control-center dialog in question is currently relying on this expectation). Looking at https://git.gnome.org/browse/gnome-control-center/tree/panels/datetime/cc-datetime-panel.c , making the imply relation end-user overridable wouldn’t even help, exactly due to this expectation: * control-center only checks o.g.c.datetime.policy, and allows/prohibits access to all its UI widgets as a unit, not at the desired granularity (namely to let the users change time zones but not anything else). * It also doesn’t handle permission failures that would happen if the user _could_ override the results, e.g. looking at set_using_ntp_cb. So if the desired end-user use case were to be supported by gnome-control-center, it would have to query the individual o.f.timedate1.* permissions and allow for systems that give the users access to some but not all of them, by enabling individual relevant widgets if the corresponding individual actions are allowed without authorization, and keeping the existing lock button / o.g.controlcenter.datetime.configure action to enable editing the rest. (It could also, I think quite reasonably, be argued that the timezone setting should just be determined automatically from location and then users wouldn't need to use the dialog and wouldn’t need the permission at all, so all this extra functionality shouldn’t need to be added to the panel; but that depends on the automatic system being reliable and trusted enough. I don’t know whether it is.) This change will need to be done upstream. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |