Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Description of problem: ssh to any host pauses for 20 seconds. Version-Release number of selected component (if applicable): selinux-policy-3.7.19-69.fc13.noarch.rpm selinux-policy-targeted-3.7.19-69.fc13.noarch.rpm How reproducible: Always Steps to Reproduce: 1. Set desktop to KDE 2. Enable selinux 3. ssh hostname Actual results: 20-second pause before login succeeds Expected results: No pause Additional info: /var/log/messages says setroubleshoot: SELinux is preventing /usr/bin/xauth "write" access to /home/username/.kde/tmp-myhostname. For complete SELinux messages, run sealert -l xxxxxxxxx Typing setenforce 0 restores system to full speed. --- Note: In bugzilla, pressing 'enter' while typing the bug summary line causes the bug to be submitted before you've had a chance to fill in the rest of the form. Sorry about the mostly-empty email.
What is /.kde/tmp-myhostname
~/.kde/tmp-`hostname` is a symlink pointing to /tmp/kde-`username` Similarly, ~/.kde/cache-`hostname` => /var/tmp/kdecache-`username` ~/.kde/socket`hostname` => /tmp/ksocket-`username`
/home/croot/.kde/tmp-fedora13.localnet is a directory; inside it, there are a number of temporary files, one of which is 'xauth-0-_0', the typical .Xauthority file containing a hostname and MIT-MAGIC-COOKIE-1. My computer's name is fedora13.localnet, so I just substituted 'myhostname' when writing the bug report. I have no idea why the .Xauthority file is being put there, but there you have it. Thanks
On my system, ~/.kde/tmp-`hostname` is not a symlink to /tmp/kde-`username`; /tmp/kde-`username` exists but is empty.
What does ausearch -m avc -ts recent return?
In fact, on my system, there are no symlinks in ~/.kde.
Created attachment 461630 [details] output from: ausearch -m avc -ts recent
Penelope, I think your homedir is mislabeled. restorecon -R -v /home
Aha, that worked! As an aside, is it the case that files can only become mislabelled while selinux is off, or could this have happened while selinux is on? Thanks
It can happen while SELinux is on, e.g. if you first create the file elsewhere, then use an extended-attribute-preserving copy or move to move the file to its actual destination.
Yes if you create the directory by hand it can happen, although now there should be a login daemon running at the console "restorecond" Which watches for new files/directories created in the homedir and fixes the label for you.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Since I upgraded to F15, I am experiencing the same bug. XAUTHORITY is set to /home/eric/.kde/tmp-romarin/xauth-500-_0 and when xauth tries to lock and access that file, it is blocked by selinux. I have no idea why the xauth place is put here. I am using kdm to log in, and /etc/kde/kdmrc contains the lines # Where to put the user's X-server authorization file if ~/.Xauthority # cannot be created (and ForceUserAuthDir is not true) # Default is "/tmp" UserAuthDir=/var/run/kdm ForceUserAuthDir=true Note that I have add 3 xauth file created when I logged in: -rw-rw-r--. 1 eric eric 52 31 mai 21:25 /home/eric/.kde/tmp-romarin/xauth-500-_0 -rw-------. 1 eric eric 253 31 mai 21:24 /home/eric/.Xauthority -rw-------. 1 root root 44 31 mai 21:25 /var/run/kdm/A:0-1IdDMa I imagine that the third one is a system one and the two first are user files, but why two files ? Is it really kdm who decided that the xauth file would be where xauth could not read it, or someone else ? This bug might related to 567914. I don't know how to relabel it as a F15 bug.
What avc are you seeing?
Ok, I don't understand selinux at all and I am not sure what an avc is. There are some messages in /var/log/messages stating SELinux is preventing /usr/bin/xauth from write access on the directory /home/eric/.kde/tmp-romarin. For complete SELinux messages. run sealert -l 0dfd8c14-9797-4775-a69d-8bfc12214e9f Running sealert I found this; is it what you require ? type=AVC msg=audit(1306880344.100:98): avc: denied { remove_name } for pid=3057 comm="xauth" name="xauth-500-_0-c" dev=sda2 ino=1459802 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir type=AVC msg=audit(1306880344.100:98): avc: denied { remove_name } for pid=3057 comm="xauth" name="xauth-500-_0-c" dev=sda2 ino=1459802 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir type=AVC msg=audit(1306880344.100:98): avc: denied { unlink } for pid=3057 comm="xauth" name="xauth-500-_0-c" dev=sda2 ino=1459802 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=file type=SYSCALL msg=audit(1306880344.100:98): arch=x86_64 syscall=unlink success=yes exit=0 a0=7fffd545abd0 a1=3b51001b5d a2=3d9 a3=7fffd545afe0 items=0 ppid=2977 pid=3057 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts5 ses=1 comm=xauth exe=/usr/bin/xauth subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) Hash: xauth,xauth_t,config_home_t,dir,remove_name
is /home/eric/.kde/tmp-romarin a pointer to /tmp? If you rm -rf ~/.kde/tmp-romarin Does everything begin to work?
No, and Yes: /home/eric/.kde/tmp-romarin was not a pointer but a real directory. I killed the X server, it restarted. Before logging, I went on a text console to rm -rf ~/.kde/tmp-romarin . After logginf, 1) xauth was working fine, 2) tmp-romarin was recreated as a pointer to /tmp/kde-eric, 3) XAUTHORITY was set to /tmp/kde-eric/xauth-500-_0 Ok, so I suppose this tmp-romarin is meant to be a link and not a directory. I have no idea when it changed. Thanks for the help.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping