Version: unspecified (using Devel) OS: Linux On logout, kdm overwrites file ~/.Xauthority with wrong SELinux contexts, thus preventing e.g. ssh daemon to write xauth data into it when logging over ssh with X forwarding enabled. As a consequence, X programs cannot be run over ssh due to wrong credentials. Reproducible: Always Steps to Reproduce: 1. Install a system with SELinux enabled - I've done my testing on Fedora (12, 13). 2. Log in via ssh with X forwarding enabled, log out. 3. Log in locally via kdm, log out. 4. Log in via ssh again. Actual Results: 2. $ ssh -p 2222 virtual@localhost virtual@localhost's password: Last login: Fri Jun 18 12:45:23 2010 from 10.0.2.2 /usr/bin/xauth: creating new authority file /home/virtual/.Xauthority [virtual@virtual ~]$ ls -lZ .Xauthority -rw-------. virtual virtual unconfined_u:object_r:xauth_home_t:s0 .Xauthority 4. $ ssh -p 2222 virtual@localhost virtual@localhost's password: Last login: Fri Jun 18 12:54:04 2010 /usr/bin/xauth: /home/virtual/.Xauthority not writable, changes will be ignored [virtual@virtual ~]$ ls -lZ .Xauthority -rw-------. virtual virtual system_u:object_r:xdm_home_t:s0 .Xauthority Expected Results: xauth should be able to write to ~/.Xauthority - the selinux type should not change from xauth_home_t to xdm_home_t This was originally reported as Fedora bug #567914 (https://bugzilla.redhat.com/show_bug.cgi?id=567914) Based on comments #15 and #16, it seems the real cause of the problem is that under some circumstances, kdm uses ~/.Xauthority instead of an authority file put into /var/run/kdm dir. Note, the bugzilla field KDE Version does not allow me to specify KDE 4.4.4 - the package version I've just verified the bug presence with is kdm-4.4.4-1.fc13.x86_64
the reason for that is pretty obvious and not particularly unexpected: kdm (like xdm) just creates a new file with the modified contents and then renames it over the old file, having absolutely no knowledge of selinux. wouldn't it be the task of pam_selinux to set up things appropriately, so kdm doing its normal thing would Just Work?
i'll close this wontfix if no interested party investigates the correct solution.
I am having this same problem with F16 kdm-4.7.2-14. After working on this problem with some members of fedora forum, it was brought to my attention this is a bug and I feel that many people would like to see it fixed. However I think the selinux context label of ~/.Xauthority is actually changed on log-in. To view the thread I started at fedora forum visit http://forums.fedoraforum.org/showthread.php?t=271762&page=3
For what it's worth, fedora now defaults to kdmrc including: UserAuthDir=/var/run/kdm ForceUserAuthDir=true so, I'm a little surprised how this (problems with ~/.Xauthority) is still happening in some cases.
Digging further, I think I see in auth.c, a case where StartuserAuth gets called unconditionally from removeuserAuthorization , which seems to match up with symptoms reported where a mysterious (and empty) ~/.Xauthority gets created on log out.
So, I think I've discovered a side-effect, that removeUserAuthorization doesn't process anything != ~/.Xauthority Not sure how bad that is... though, given that this behavior has been around for quite awhile, maybe not so much. so, for now, I'm going to simply try to make removeUserAuthorization bail out if forceUserAuthDir is true (could add extra paranoia, say if XAUTHORITY env is also set)
Created attachment 67412 [details] bail out of removeUserAuthorization if d->forceUserAuthDir set Initial and naive workaround. I'm guessing removeUserAuthorization probably ought to handle != ~/.Xauthority too
KDE 4.14 problem still here
Alex, you're experiencing this bug on fedora? If not, I'd encourage you to consider configuring kdmrc per comment #4 and apply the patch from comment #7
Hi Rex! I'm using Debian Jessie, already try config from comment #4, it does not working. I'll try to apply the patch in the next 2-3 days.
KDM is unmaintained and not used in KDE Plasma 5. SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/