Description of problem: SELinux is preventing xauth from creating a new version of the xauth file in ~/.kde/tmp-<host>/ which it can then rename over the current xauth file. warthog>time /usr/bin/xauth -f /home/dhowells/.kde/tmp-warthog.procyon.org.uk/auth-4043-_0 nlist :0.0 /usr/bin/xauth: timeout in locking authority file /home/dhowells/.kde/tmp-warthog.procyon.org.uk/auth-4043-_0 real 0m20.003s user 0m0.001s sys 0m0.001s Running it under strace shows a number of these: open("/home/dhowells/.kde/tmp-warthog.procyon.org.uk/auth-4043-_0-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) when SELinux is in Enforcing mode. There appear to be two problems. The first is that processes running as xauth_t doesn't have permission to do things with files of label config_home_t. This can be rectified with the following policy addition: module local_xauth 1.0; require { type xauth_t; type config_home_t; class dir { write remove_name add_name }; class file { link create unlink open }; } allow xauth_t config_home_t:dir { write remove_name add_name }; allow xauth_t config_home_t:file { open create unlink link }; The second problem is not obvious. If I turn Enforcing mode off, then I see the audit records for the above until I've loaded the module. But if Enforcing mode is on, I don't see any audit records for the above, and it doesn't work, even if I have the module loaded. I'm fairly certain this worked before the latest upgrade of selinux. It's noticeable because 'su' now takes 20 secs or so to go from password to prompt, and I can't start X programs from within the su session without setting the XAUTHORITY envvar manually. Additionally, "ssh -X" gives a lot of connection failed errors before letting remote X programs connect to the server. Version-Release number of selected component (if applicable): kdebase-4.5.5-1.fc14.x86_64 xorg-x11-xauth-1.0.2-7.fc12.x86_64 selinux-policy-3.9.7-29.fc14.noarch I'm fairly certain this worked in the previous version of the policy. My updates to this are as follows: [root@warthog selinux]# grep selinux-policy-3 /var/log/yum.log Jan 04 13:47:10 Updated: selinux-policy-3.9.7-19.fc14.noarch Jan 19 12:05:54 Updated: selinux-policy-3.9.7-20.fc14.noarch Jan 28 10:35:53 Updated: selinux-policy-3.9.7-25.fc14.noarch Feb 04 23:05:52 Updated: selinux-policy-3.9.7-28.fc14.noarch Feb 11 13:35:26 Updated: selinux-policy-3.9.7-29.fc14.noarch
We added this label HOME_DIR/\.kde(/.*)? gen_context(system_u:object_r:config_home_t,s0) But actually if you try to execute # restorecon -Rv /home/dhowells/.kde/tmp-warthog.procyon.org.uk does it work then?
# ls -dZ /home/mgrepl/.kde/tmp-avalanche/ drwx------. mgrepl mgrepl unconfined_u:object_r:user_tmp_t:s0 /home/mgrepl/.kde/tmp-avalanche/ # ls -Z /home/mgrepl/.kde/tmp-avalanche/xauth-500-_0 -rw-rw-r--. mgrepl mgrepl unconfined_u:object_r:user_tmp_t:s0 /home/mgrepl/.kde/tmp-avalanche/xauth-500-_0 and we have in the policy ifdef(`hide_broken_symptoms',` ... userdom_manage_user_home_content_files(xauth_t) userdom_manage_user_tmp_files(xauth_t) ... ') So it looks like I will need to allow xauth to manage gnome config files too.
I am building a scratch build. Could you test it with this scratch build? http://koji.fedoraproject.org/koji/taskinfo?taskID=2844130
(In reply to comment #1) > ... > But actually if you try to execute > > # restorecon -Rv /home/dhowells/.kde/tmp-warthog.procyon.org.uk > > does it work then? No. It makes no difference to the labelling of the directory and the xauth file. They were both config_home_t before and they are still afterwards.
(In reply to comment #2) > # ls -dZ /home/mgrepl/.kde/tmp-avalanche/ > drwx------. mgrepl mgrepl unconfined_u:object_r:user_tmp_t:s0 > /home/mgrepl/.kde/tmp-avalanche/ How come your .kde/tmp-<host>/ dir appears as user_tmp_t and mine appears as config_home_t?
(In reply to comment #3) > I am building a scratch build. Could you test it with this scratch build? > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2844130 That seems to work.
Actually the problem is a link # ls -lZ /home/mgrepl/.kde/ lrwxrwxrwx. mgrepl mgrepl unconfined_u:object_r:config_home_t:s0 cache-avalanche -> /var/tmp/kdecache-mgrepl drwx------. mgrepl mgrepl unconfined_u:object_r:config_home_t:s0 share lrwxrwxrwx. mgrepl mgrepl unconfined_u:object_r:config_home_t:s0 socket-avalanche -> /tmp/ksocket-mgrepl lrwxrwxrwx. mgrepl mgrepl unconfined_u:object_r:config_home_t:s0 tmp-avalanche -> /tmp/kde-mgrepl Could you test it with the scratch build?
Great. Thanks for testing.
Fixed in selinux-policy-3.9.7-31.fc14
selinux-policy-3.9.7-31.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-31.fc14
selinux-policy-3.9.7-31.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-31.fc14
selinux-policy-3.9.7-31.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.