Description of problem: Cannot set system date/time via gnome-panel clock Version-Release number of selected component (if applicable): system-config-date-1.9.0-1.fc7 How reproducible: Rightclick on the clock in the Gnome panel and choose "Change date/time" Steps to Reproduce: 1. Rightclick on the clock in the Gnome panel 2. Choose change date/time 3. Enter root password Actual results: A root passwd dialog appears, SELinux prevents system-config-date from running Expected results: system-config-date should appear as usual Additional info: I have triggered /.autorelabel in case this problem is not reproducable
Have you tried running it without SELinux? I think this is not an SELinux problem as it is present with SELinux enforcing and permissive. I've digged a bit into this and found that the clock applet doesn't pass on environment variables necessary to run X applications. As a result, s-c-date tries to run in text mode which is a hopeless endeavour right from the beginning without a terminal in which to write. I'll attach a diff of my environment in a terminal window and of the environment when started from the clock applet (which shows that it e.g. doesn't inherit XAUTHORITY, DBUS_SESSION_BUS_ADDRESS, ...) and change the component to gnome-panel. Ray, it seems the clock applet reads the prefs/config_tool gconf key only once, it would be good if it reads that key every time someone clicks on "Adjust Date & Time", this would make debugging easier among other things.
Created attachment 156183 [details] diff between environment in terminal and from the clock applet
Strange, this time it just works, with SELinux enforcing that is. All I did was apply all updates and install some additional software, however to the best of my knowledge nothing either SELinux related or system-config-date/gnome-panel?? Just to point out I not just wasting your time, this was the original SELinux alert, that brought me to file this bugreport in the first place: Summary SELinux is preventing /usr/sbin/userhelper (mono_t) "transition" to /usr/share/system-config-date/system-config-date.py (unconfined_t). Detailed Description SELinux denied access requested by /usr/sbin/userhelper. It is not expected that this access is required by /usr/sbin/userhelper and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context user_u:system_r:mono_t Target Context system_u:system_r:unconfined_t Target Objects /usr/share/system-config-date/system-config- date.py [ process ] Affected RPM Packages usermode-1.91.1-1 [application]system-config- date-1.9.0-1.fc7 [target] Policy RPM selinux-policy-2.6.4-8.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall Host Name neo.lokaal.net Platform Linux neo.lokaal.net 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:47:07 EDT 2007 x86_64 x86_64 Alert Count 1 First Seen ma 04 jun 2007 21:08:54 CEST Last Seen ma 04 jun 2007 21:08:54 CEST Local ID ef046bc1-7f6f-4525-a55b-d049fc93ec36 Line Numbers Raw Audit Messages avc: denied { transition } for comm="userhelper" dev=dm-2 egid=0 euid=0 exe="/usr/sbin/userhelper" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="system- config-date.py" path="/usr/share/system-config-date/system-config-date.py" pid=16752 scontext=user_u:system_r:mono_t:s0 sgid=0 subj=user_u:system_r:mono_t:s0 suid=0 tclass=process tcontext=system_u:system_r:unconfined_t:s0 tty=(none) uid=0
Well, I'm sure mono_t isn't the right context type for the userhelper binary, that would explain things (maybe even not passing on env variables, who knows?). I'd close this now. Ray, shall I open a new bug for the issue with prefs/config_tool only being read once?
Nils, yes please. (maybe an upstream one?)