Bug 242065

Summary:	kdm overwrites ~/.Xauthority with wrong SELinux context on logout
Product:	[Unmaintained] kdm	Reporter:	kavol <kavol>
Component:	general	Assignee:	kdm bugs tracker <kdm-bugs-null>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	alex, ramesses21, rdieter
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	bail out of removeUserAuthorization if d->forceUserAuthDir set

Description kavol 2010-06-18 13:05:34 UTC

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

Comment 1 Oswald Buddenhagen 2010-07-31 21:44:24 UTC

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?

Comment 2 Oswald Buddenhagen 2010-10-24 18:23:31 UTC

i'll close this wontfix if no interested party investigates the correct solution.

Comment 3 ramesses21 2011-12-16 05:17:26 UTC

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

Comment 4 Rex Dieter 2011-12-16 12:49:33 UTC

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.

Comment 5 Rex Dieter 2012-01-03 19:53:14 UTC

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.

Comment 6 Rex Dieter 2012-01-03 20:34:24 UTC

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)

Comment 7 Rex Dieter 2012-01-03 20:51:52 UTC

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

Comment 8 Alex Lushpai 2014-10-02 09:52:36 UTC

KDE 4.14
problem still here

Comment 9 Rex Dieter 2014-10-02 18:10:28 UTC

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

Comment 10 Alex Lushpai 2014-10-03 09:52:06 UTC

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.

Comment 11 Nate Graham 2018-04-16 20:23:03 UTC

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/