Red Hat Bugzilla – Bug 119769
cannot run as user
Last modified: 2013-07-02 18:59:49 EDT
Description of problem: [scott@localhost scott]$ system-logviewer Could not set exec context to user_u:sysadm_r:sysadm_t. [scott@localhost scott]$ su Password: [root@localhost scott]# sysetm-logviewer bash: sysetm-logviewer: command not found [root@localhost scott]# system-logviewer /usr/share/system-logviewer/LogFileFrame.py:121: DeprecationWarning: but we use it for a constructor for convenience self.searchEntry = gtk.Entry() [root@localhost scott]# This happens with all system-* How reproducible: every time Steps to Reproduce: 1. from user, try and launch and of the system- programs 2. type in root password 3. they die Actual results: program is killed Expected results: program should launch Additional info: if this is not a bug then all system programs should be removed from the user menu. what is the point of the user seeing them if they can't not run them even if they know the root password
Created attachment 99071 [details] strace output
This looks like it might be a symptom of SELinux. Please disable SELinux with the setenforce 0 command as described at http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/, try to run system-logviewer as a user again, and let me know what happens.
With Setting: /etc/sysconfig/selinux selinux=disabled I can start system-* succssfully, so you're right Tammy in that this is a direct symptom of selinux.
After further investigation, it looks like userhelper is dumping out the Could not set exec context to user_u:sysadm_r:sysadm_t error message. I am changing the component to usermode.
FWIW, this works for users created with 'useradd' (i.e. with sysadm_r), but not with seuser add -R user_r (i.e. with user_r). [tim@tornado tim]$ id -Z tim:user_r:user_t [tim@tornado tim]$ gdmsetup Could not set exec context to tim:sysadm_r:sysadm_t. [foo@tornado foo]$ id -Z user_u:sysadm_r:sysadm_t [foo@tornado foo]$ gdmsetup [asks for password, then works]
*** Bug 119602 has been marked as a duplicate of this bug. ***
*** Bug 119858 has been marked as a duplicate of this bug. ***
Current policy fixes this problem