Summary: SELinux is preventing the /usr/bin/xauth from using potentially mislabeled files (xauth.XXXXulGkJY). Detailed Description: SELinux has denied xauth access to potentially mislabeled file(s) (xauth.XXXXulGkJY). This means that SELinux will not allow xauth to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want xauth to access this files, you need to relabel them using restorecon -v 'xauth.XXXXulGkJY'. You might want to relabel the entire directory using restorecon -R -v ''. Additional Information: Source Context unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:user_tmp_t:s0 Target Objects xauth.XXXXulGkJY [ file ] Source xauth Source Path /usr/bin/xauth Port <Unknown> Host (removed) Source RPM Packages xorg-x11-xauth-1.0.2-7.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-39.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name (removed) Platform Linux (removed) 2.6.31.5-112.fc12.x86_64 #1 SMP Tue Nov 3 00:28:52 EST 2009 x86_64 x86_64 Alert Count 1 First Seen Tue 03 Nov 2009 06:27:48 PM CET Last Seen Tue 03 Nov 2009 06:27:48 PM CET Local ID 2dc04747-1cfb-4428-a422-f21c03187e28 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1257269268.83:27041): avc: denied { unlink } for pid=3104 comm="xauth" name="xauth.XXXXulGkJY" dev=sda3 ino=9145 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1257269268.83:27041): arch=c000003e syscall=87 success=no exit=-13 a0=11c6010 a1=34c4d7be80 a2=e2f a3=1 items=0 ppid=3103 pid=3104 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=1 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-39.fc12,home_tmp_bad_labels,xauth,xauth_t,user_tmp_t,file,unlink audit2allow suggests: #============= xauth_t ============== allow xauth_t user_tmp_t:file unlink;
this looks like other "xauth" selinux denials, but (at least for me) this one is different: 1) not in home, but in /tmp/ 2) I'm using latest selinux-policy I've found in koji, where (afaik) the ordinary "xauth" problem should be fixed 3) this reports file as misslabeled, but when I do "ls -Z /tmp" the file is there, but with different context: -rw-------. root root unconfined_u:object_r:xauth_tmp_t:s0 xauth.XXXXCu1LDS-n
this selinux denial is preventing me from using system settings in kde that require root password first (for example login manager and samba)
this is simplified reproducer: /usr/libexec/kde4/kdesu -c /bin/true it means that everything what requires root privileges in kde (and is not using policykit or something like that) wont work
also bug #531746 is required to get kdesu work
up'd to 3.6.32-40.fc12 problem remained. This is indeed bad news, adding to the -kde spin blocker
Does kdesu create a file in /tmp and then mv it to /root? Or does it leave it in /tmp? I can add a allow rule for F12 in Fixed in selinux-policy-3.6.32-41.fc12.noarch But I would like to fix the behaviour to act correctly.
was this really fixed or it was just closed by bot?
Maybe I am a bot. No I have allowed the access bug I need the kdesu people to explain how their app works? Relying on root objects looking at the same /tmp as the user might be a mistake.
Thanks. Anyone know of how kdesu works, or wants the task to find out (by looking at code, or asking upstream)? (I'll test the selinux workaround, and drop from the tracker).
Hrm, I see no newer selinux-policy builds yet, so I guess I can't test anything. Dan, please ping us (or rel-eng folks) when it is.
selinux-policy-3.6.32-41.fc12 confirmed good.
please don't drop the bug from the blocker list; that makes those of us working on the blocker list lose track of it. we can't be sure the issue's taken care of properly until the fixed build is tagged. tag request is: https://fedorahosted.org/rel-eng/ticket/3088 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'll queue up a retest and report back shortly ...
Also tested and confirmed the fix using selinux-policy-3.6.32-41.fc12. Thanks for the simple reproducer: /usr/libexec/kde4/kdesu -c /bin/true
selinux-policy-3.6.32-41.fc12 has been tagged and the fix has been confirmed multiple times. Moving this issue to MODIFIED, then CLOSED RAWHIDE.
*** Bug 533096 has been marked as a duplicate of this bug. ***