Red Hat Bugzilla – Bug 442585
SELinux policy prevents clock applet from setting timezone
Last modified: 2009-10-20 18:05:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041504 Minefield/3.0pre
Description of problem:
In the calendar/locations popup you get when right-clicking the clock applet, if you attempt to set the timezone to a location listed there by clicking the 'Set' button (which should appear when hovering over the location entry), an SELinux error prevents this from being set. (selinux trouble shooter output is attached)
This not only prevents you from setting the time zone from the clock applet, but it prevents you from seeing the weather and temperature for your location in the panel applet.
Also note that there is no policykit dialog presented to authenticate this timezone change.
Possibly applicable package installed versions:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Ensure SELinux enforcement policy is 'Enforcing'
2. Ensure locations have been added to clock preferences
3. right-click clock
4. hover over location to reveal 'Set' button
5. click 'Set' button
An SELinux denial is thrown, timezone and current location are not set, so no weather can be displayed in the clock applet.
policykit authentication dialog should appear, Timezone should be set, current location should be set (resulting in a house icon shown next to the location in the popup), and weather and temp info should appear in the task bar if the clock is configured to show weather and temp in the preferences.
I filed a gnome bug on this initially (http://bugzilla.gnome.org/show_bug.cgi?id=528145) before deducing that this was an SELinux policy issue.
Created attachment 302498 [details]
SELinux troubleshooter ourput for denial when 'Set' button clicked
This is the SELinux output when the denial is thrown.
Changing selinux enforcement to 'Permissive' allows this to work just fine, but
the same error is thrown.
Why would gnomeclock need sys_ptrace?
I believe it has to do with policykit, which is what
gnome-clock-applet-mechanism is responsible for
Could policykit's use of the prctl() system call (to prevent ptrace from being
used to snoop on policykit support programs) have something to do with this?
After some testing, I believe the context of
/usr/libexec/gnome-clock-applet-mechanism is is wrong, or the context
system_u:object_r:gnomeclock_exec_t:s0 needs more capabilities.
By default, /usr/libexec/gnome-clock-applet-mechanism has the context
system_u:object_r:gnomeclock_exec_t:s0. If I set the context to
system_u:object_r:bin_t:s0, like other similar policykit helpers, then the clock
applet allows me to set the timezone with no SELinux errors.
Ok, I have added that capability (sys_ptrace) to gnomeclock_t, which the file
context on disk requires.
gnomeclock is also allowed to change the system time which polickit helpers are
not allowed to do.
Fixed in selinux-policy-3.3.1-36.fc9