Bug 242552 - Clock applet doesn't pass on environment to system-config-date when adjusting date/time
Clock applet doesn't pass on environment to system-config-date when adjusting...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: gnome-panel (Show other bugs)
7
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-04 15:34 EDT by Jeroen Beerstra
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-06 10:56:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
diff between environment in terminal and from the clock applet (2.38 KB, text/plain)
2007-06-05 03:51 EDT, Nils Philippsen
no flags Details

  None (edit)
Description Jeroen Beerstra 2007-06-04 15:34:20 EDT
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
Comment 1 Nils Philippsen 2007-06-05 03:50:19 EDT
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.
Comment 2 Nils Philippsen 2007-06-05 03:51:29 EDT
Created attachment 156183 [details]
diff between environment in terminal and from the clock applet
Comment 3 Jeroen Beerstra 2007-06-05 11:26:50 EDT
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 
Comment 4 Nils Philippsen 2007-06-06 06:41:04 EDT
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?
Comment 5 Ray Strode [halfline] 2007-06-06 10:56:51 EDT
Nils, yes please. (maybe an upstream one?)

Note You need to log in before you can comment on or make changes to this bug.