Are you sure you are using xdm?  It stores its Xauthority files outside of the homedir.
echo $XAUTHORITY 
/var/run/gdm/auth-for-dwalsh-gHE0bI/database

(In reply to comment #1)
> Are you sure you are using xdm?  It stores its Xauthority files outside of the
> homedir.
> echo $XAUTHORITY 
> /var/run/gdm/auth-for-dwalsh-gHE0bI/database    

ah, right ... I was mistaken by the look of the login screen, in fact it is KDM, sorry

and it seems to put the file in /var too:

$ echo $XAUTHORITY
/var/run/kdm/.XauthnLul61

$ ls -lZ /var/run/kdm/.XauthnLul61
-rw-------. kavol kavol system_u:object_r:xdm_var_run_t:s0 /var/run/kdm/.XauthnLul61

in that case, the question is what else can keep changing the context of ~/.Xauthority? - or else, what fixes need to be done to ssh/xauth to work with the proper context?

Something in kde is creating this file, rather then using the environment variable.

What avc's are you seeing when you login as ssh after logging in with kdm?

probably a round-about dup of bug #524583

Make sure you have the following in /etc/kde/kdm/kdmrc:

[X-*-Core]
UserAuthDir=/var/run/kdm
ForceUserAuthDir=true

[General]
AuthDir=/var/run/kdm

(these entries should be included by default, unless you've customized kdmrc)

Reporter can you please advise if the suggestion in comment #4 solved the issue for you?

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Created attachment 403671 [details]
kdmrc

here is my kdmrc

the mentioned settings are there

(In reply to comment #3)
> Something in kde is creating this file, rather then using the environment
> variable.
> 
> What avc's are you seeing when you login as ssh after logging in with kdm?    

type=USER_ACCT msg=audit(1270028732.191:41): user pid=1919 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="kavol" exe="/usr/sbin/sshd" hostname=192.168.1.254 addr=192.168.1.254 terminal=ssh res=success'
type=CRED_ACQ msg=audit(1270028732.195:42): user pid=1919 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="kavol" exe="/usr/sbin/sshd" hostname=192.168.1.254 addr=192.168.1.254 terminal=ssh res=success'
type=LOGIN msg=audit(1270028732.196:43): login pid=1919 uid=0 old auid=4294967295 new auid=500 old ses=4294967295 new ses=4
type=USER_ROLE_CHANGE msg=audit(1270028732.261:44): user pid=1919 uid=0 auid=500 ses=4 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=?: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=failed'
type=USER_ROLE_CHANGE msg=audit(1270028732.262:45): user pid=1919 uid=0 auid=500 ses=4 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1270028732.269:46): user pid=1919 uid=0 auid=500 ses=4 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="kavol" exe="/usr/sbin/sshd" hostname=192.168.1.254 addr=192.168.1.254 terminal=ssh res=success'
type=CRED_ACQ msg=audit(1270028732.273:47): user pid=1922 uid=0 auid=500 ses=4 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="kavol" exe="/usr/sbin/sshd" hostname=192.168.1.254 addr=192.168.1.254 terminal=ssh res=success'
type=USER_LOGIN msg=audit(1270028732.463:48): user pid=1919 uid=0 auid=500 ses=4 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=500 exe="/usr/sbin/sshd" hostname=192.168.1.254 addr=192.168.1.254 terminal=/dev/pts/1 res=success'

None of those are AVC messages.  They are regular audit messages.

Remove the .Xauthority record from the homedir, then ssh in, and see what context it gets created with.

(In reply to comment #8)
> None of those are AVC messages.  They are regular audit messages.    

yeah, true, but that is all I got from audit.log ...

(In reply to comment #9)
> Remove the .Xauthority record from the homedir, then ssh in, and see what
> context it gets created with.    

still the same:

$ ls -lZ ~/.Xauthority 
-rw-------. kavol kavol unconfined_u:object_r:xauth_home_t:s0 /home/kavol/.Xauthority

That is the right label.

(In reply to comment #11)
> That is the right label.    

ok, then why it gets changed to system_u:object_r:xdm_home_t:s0 ?

is there a (simple) way to setup some "trap" to see what changes the context?

You can put a watch on the file via the audit system

something like

# auditctl -w /home/kavol/.Xauthority     -p w 

You are saying now that the context is correct, if you login via kdm it will change to xdm_home_t.

hope this is the relevant part of the log - I see when the context changes, but I don't understand what changes it ...

type=USER_AUTH msg=audit(1270141182.670:19342): user pid=1662 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="kavol" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success'
type=USER_ACCT msg=audit(1270141182.678:19343): user pid=1662 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="kavol" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success'
type=CRED_ACQ msg=audit(1270141182.818:19344): user pid=1662 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="kavol" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success'
type=LOGIN msg=audit(1270141182.818:19345): login pid=1662 uid=0 old auid=4294967295 new auid=500 old ses=4294967295 new ses=5
type=USER_ROLE_CHANGE msg=audit(1270141182.901:19346): user pid=1662 uid=0 auid=500 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/bin/kdm" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1270141182.907:19347): user pid=1662 uid=0 auid=500 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="kavol" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success'
type=USER_AUTH msg=audit(1270141642.421:19348): user pid=3123 uid=500 auid=500 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/2 res=failed'
type=USER_AUTH msg=audit(1270141645.691:19349): user pid=3129 uid=500 auid=500 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/2 res=success'
type=USER_ACCT msg=audit(1270141645.697:19350): user pid=3129 uid=500 auid=500 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/2 res=success'
type=USER_START msg=audit(1270141646.338:19351): user pid=3129 uid=500 auid=500 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/2 res=success'
type=CRED_ACQ msg=audit(1270141646.344:19352): user pid=3129 uid=500 auid=500 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/2 res=success'
type=CRED_DISP msg=audit(1270141786.879:19353): user pid=3129 uid=500 auid=500 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/2 res=success'
type=USER_END msg=audit(1270141786.884:19354): user pid=3129 uid=500 auid=500 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/2 res=success'
type=CONFIG_CHANGE msg=audit(1270141789.105:19355): auid=500 ses=5 op="updated rules" path="/home/kavol/.Xauthority" key=(null) list=4 res=1
type=CONFIG_CHANGE msg=audit(1270141789.105:19356): auid=500 ses=5 op="updated rules" path="/home/kavol/.Xauthority" key=(null) list=4 res=1
type=SYSCALL msg=audit(1270141789.105:19357): arch=40000003 syscall=38 success=yes exit=0 a0=bfb0800a a1=bfb0840c a2=bfb0840c a3=bfb0800a items=5 ppid=1662 pid=3268 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=5 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1270141789.105:19357):  cwd="/"
type=PATH msg=audit(1270141789.105:19357): item=0 name="/home/kavol/" inode=132596 dev=fd:00 mode=040755 ouid=500 ogid=500 rdev=00:00 obj=unconfined_u:object_r:user_home_dir_t:s0
type=PATH msg=audit(1270141789.105:19357): item=1 name="/home/kavol/" inode=132596 dev=fd:00 mode=040755 ouid=500 ogid=500 rdev=00:00 obj=unconfined_u:object_r:user_home_dir_t:s0
type=PATH msg=audit(1270141789.105:19357): item=2 name="/home/kavol/.Xauthority-n" inode=134145 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=system_u:object_r:xdm_home_t:s0
type=PATH msg=audit(1270141789.105:19357): item=3 name="/home/kavol/.Xauthority" inode=134143 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=unconfined_u:object_r:xauth_home_t:s0
type=PATH msg=audit(1270141789.105:19357): item=4 name="/home/kavol/.Xauthority" inode=134145 dev=fd:00 mode=0100600 ouid=500 ogid=500 rdev=00:00 obj=system_u:object_r:xdm_home_t:s0
type=USER_END msg=audit(1270141789.163:19358): user pid=1662 uid=0 auid=500 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="kavol" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success'
type=CRED_DISP msg=audit(1270141789.165:19359): user pid=1662 uid=0 auid=500 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="kavol" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success'
type=AVC msg=audit(1270141792.798:19360): avc:  denied  { write } for  pid=3280 comm="kdm_greet" name="fontconfig" dev=dm-0 ino=40964 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fonts_t:s0 tclass=dir
type=SYSCALL msg=audit(1270141792.798:19360): arch=40000003 syscall=33 success=no exit=-13 a0=9ffacb0 a1=3 a2=3a971a8 a3=9ffacb0 items=1 ppid=3275 pid=3280 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm_greet" exe="/usr/libexec/kde4/kdm_greet" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1270141792.798:19360):  cwd="/"
type=PATH msg=audit(1270141792.798:19360): item=0 name="/var/cache/fontconfig" inode=40964 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:fonts_t:s0
type=AVC msg=audit(1270141792.798:19361): avc:  denied  { setattr } for  pid=3280 comm="kdm_greet" name="fontconfig" dev=dm-0 ino=40964 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fonts_t:s0 tclass=dir
type=SYSCALL msg=audit(1270141792.798:19361): arch=40000003 syscall=15 success=no exit=-13 a0=9ffacb0 a1=1ed a2=3a971a8 a3=9ffacb0 items=1 ppid=3275 pid=3280 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm_greet" exe="/usr/libexec/kde4/kdm_greet" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1270141792.798:19361):  cwd="/"
type=PATH msg=audit(1270141792.798:19361): item=0 name="/var/cache/fontconfig" inode=40964 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:fonts_t:s0
type=USER_AUTH msg=audit(1270141927.880:19362): user pid=3275 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="kavol" exe="/usr/bin/kdm" hostname=? addr=? terminal=:0 res=success'

Yes that shows kdm is the one changing the file.

Looks like /usr/bin/kdm is replacing the correctly labeled .Xauthority file with one labeled xdm_home_t.   xdm_home_t is the default label for all files created by xdm_t in the users homedir.  It is supposed to only create .xsession_errors and maybe .dmrc.

Since kdm is creating the Xauthority file i n/var/lib, why is it still creating the file in the homedir?

Ugh, it would appear that kdm will use a ~/.Xauthority file, if present, else will create one in /var/run/kdm as specified in kdmrc.

hrm, maybe not, I have,

$ ls -Z ~/.Xauthority 
-rw-------. rdieter1 rdieter1 unconfined_u:object_r:xauth_home_t:s0 /home/rdieter1/.Xauthority

and
$ ls -Z /var/run/kdm/.Xauth*
-rw-------. rdieter1 rdieter1 system_u:object_r:xdm_var_run_t:s0 /var/run/kdm/.XauthceGWGG


So, I guess I can't reproduce this.

Thanks for the report.  This needs to be reported to the upstream developers.  Please file a report at http://bugs.kde.org  Then add the upstream bug information to this report.  We will monitor the upstream report for a resolution.

Thanks

I've just submitted the upstream bug:
Bug 242065 -  kdm overwrites ~/.Xauthority with wrong SELinux context on logout

The bug appears also in recent kdm-4.4.4-1.fc13, so updating the product version.

adjusting component/summary.

Also in kdm-4.5.3-3.fc14.i686.

Still present in kdm-4.6.2-2.fc14.x86_64 . And it looks like we can not expect any fix from upstream.

It's quite annoying that I have to run "resorecon ~/.Xauthority" and "rm ~/.Xauthority-*" and disconnect/connect again to get X forward working.

Well I just added a fix to F16 that will cause xdm_t to create .Xauthority with the correctly label.

F14,F15 also run a processes call restorecond that watches for user creation of files in the homedir and fixes the label.

You could also run the restorecond service and add the path to this file, which will relabel it if it gets created with the wrong label.

/etc/selinux/restorecond.conf or /etc/selinux/restorecond_user.conf.

(In reply to comment #23)
> Well I just added a fix to F16 that will cause xdm_t to create .Xauthority with
> the correctly label.
> 
> F14,F15 also run a processes call restorecond that watches for user creation of
> files in the homedir and fixes the label.
> 
> You could also run the restorecond service and add the path to this file, which
> will relabel it if it gets created with the wrong label.
> 
> /etc/selinux/restorecond.conf or /etc/selinux/restorecond_user.conf.

Dan,
Will etc/selinux/restorecond.conf or /etc/selinux/restorecond_user.conf accept wildcards as part of the path and not as the file? Like:

/home/*/.Xauthority

~/.Xauthority

I believe is the correct syntax

I added "~/.Xauthority" to restorecond_user.conf and the full path to restorecond.conf, activated the restorecond service and logged out.

Does not seem to help. Still had the problem with ssh and X forward.

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

the problem is still there:

$ ls -lZ ~/.Xauthority 
-rw-------. kvolny kvolny system_u:object_r:xdm_home_t:s0  /home/kvolny/.Xauthority

- there is xdm_home_t instead of xauth_home_t

according to comment #23 this is going to be fixed in F16, so updating version to F15 to keep this open

I can confirm this bug still happens with the latest KDM version in Fedora 16.

I have 2 F16 machines, and as long as I've logged in using KDM, my ~/.Xauthority file has the following context:

system_u:object_r:xdm_home_t:s0

If I manually change the context to:

unconfined_u:object_r:xauth_home_t:s0

via chcon as a regular user, I am able to remotely log in via SSH and launch applications over the forwarded tunnel correctly.  Apps launched during the running desktop session work correctly as well.

TL;DR: Bug still exists.  My kdmrc contains the recommended options as outlined in comment #4.

Could you try to remove the .Xauthority record from the homedir, then ssh in, and see what context it gets created with.

The wrong context is being set by the normal login. I use kde as the desktop manager and my desktop. Don't know whether this also happens with gnome.

When I log in using ssh, I get:

     usr/bin/xauth:  /home/jrg3/.Xauthority not writable, changes will be ignored

I then remove .Xauthority-l and .Xauthority-c and run restorecon on .Xauthority.

     restorecon -v .Xauthority 
     restorecon reset /home/jrg3/.Xauthority context 
         system_u:object_r:xdm_home_t:s0->system_u:object_r:xauth_home_t:s0

Then I exit and re-connect using ssh and get no complaints about .Xauthority again until I log in using the desktop. Once I log in using the desktop, I have to repeat the process if I want to ssh to the host.

So, here on my box, kde doesn't create or touch ~/.Xauthority at all.

What happens for me, is I get this set on login:
XAUTHORITY=/tmp/kde-rdieter1/xauth-1482-_0

now, hrm... a little surprising, since kdmrc contains
UserAuthDir=/var/run/kdm
ForceUserAuthDir=true
I'd expect that to get used... (but let's deal with that oddity separately).

Point is... remote ssh connections, obviously don't know about any local XAUTHORITY env var.  My best guess is that ssh/sshd tries to fall back to using ~/.Xauthority , and *that* is the fail here.

When you remove the ~/.Xauthority file from your homedir, and login on F16, if the file is created by xdm_t it should be created as xauth_home_t, if a temporary file is created and then renamed, we might be missing this. 

If you remove the ~/.Xauthority file and login for the first time with sshd_t, what context does it get?

Miroslav we might want to add
	xserver_filetrans_home_content(sshd_t)

if sshd is creating this file rather then a process being run as a user context.

On my f16 box,

$ rm -f ~/.Xauthority

$ ssh -X localhost

/usr/bin/xauth: file /home/rdieter1/.Xauthority does not exist
$ ls -lZ .Xauthority
-rw-------. rdieter1 rdieter1 unconfined_u:object_r:xauth_home_t:s0 .Xauthority

(In reply to comment #30)
> Could you try to remove the .Xauthority record from the homedir, then ssh in,
> and see what context it gets created with.

[vector@dirty ~]$ rm .Xauthority 
[vector@dirty ~]$ ssh -X localhost
Last login: Tue Jan  3 10:30:15 2012 from localhost
/usr/bin/xauth:  file /home/vector/.Xauthority does not exist
[vector@dirty ~]$ ls -Z .Xauthority 
-rw-------. vector vector unconfined_u:object_r:xauth_home_t:s0 .Xauthority

Same as Rex in comment #34.  

(In reply to comment #32)
> Point is... remote ssh connections, obviously don't know about any local
> XAUTHORITY env var.  My best guess is that ssh/sshd tries to fall back to using
> ~/.Xauthority , and *that* is the fail here.

Specifically, I think it's the xauth binary falling back to using $HOME/.Xauthority, as that's the listed fallback if XAUTHORITY environment variable isn't set, which when you SSH into a machine, it is NOT.

It looks like when I ssh into a machine with X11 forwarding turned on, XAUTHORITY isn't set AT ALL.

[vector@dirty ~]$ env | grep XAUTH
XAUTHORITY=/tmp/kde-vector/xauth-1000-_0
[vector@dirty ~]$ ssh -X localhost
             
Last login: Tue Jan  3 10:30:28 2012 from localhost

[vector@dirty ~]$ env | grep XAUTH
[vector@dirty ~]$ 

So it looks like KDM or some other binary is setting the XAUTHORITY var.

When I tried adding the contents of that var into my .bash_profile, X11 forwarding via SSH stopped working entirely.  not sure why, not even sure if it's relevant, but there you go.

So kdm is somehow replacing this file with one that is labeled xdm_home_t?

kdm sets .Xauthority to:

     system_u:object_r:xauth_home_t:s0 .Xauthority

ssh set .Xauthority to:

     unconfined_u:object_r:xauth_home_t:s0 .Xauthority

I asserted in comment #32 that kdm isn't touching ~/.Xauthority by default *at all*.  Is there evidence to the contrary?

(In reply to comment #38)
> I asserted in comment #32 that kdm isn't touching ~/.Xauthority by default *at
> all*.  Is there evidence to the contrary?

Yes, sort of..  

I think I might have gotten a small clue on the matter...

I installed GDM and set it as my default greeter on my main workstation.  Via a remote SSH session from my laptop, I removed the .Xauthority file, and then watched it via 'watch ls -lZ ~/.Xauthority'.

I logged in from a GDM session to my KDE plasma workspace.  Then I logged out.  The entire time, .Xauthority was NOT recreated.  Then I set my greeter back to KDM.  I logged in to my KDE Plasma workspace, and still no file was created..

However, when I logged out this time, it created my .Xauthority file with the buggy context: system_u:object_r:xdm_home_t:s0

So it appears related to using KDM as the display manager and KDE as the default desktop.  

I'm about to try Gnome 3 with both KDM and GDM to see if that's doing anything weird either.

OK, well I'll be darned, it does get set... on *logout*.  wtf.  I'll have to track where that's coming from.

I now realize this data was known after re-reading the bug report..  But still, I think I know _why_ it's doing that..  I presume that since KDE+KDM set the XAUTHORITY variable somewhere other than a known default, that once a user logs out, it's trying to re-establish a sane default.  It's simply doing so using a system_u instead of unconfined_u, which no doubt is because of the context in which KDM runs.  

BTW, I tried LXDE and KDM, and the issue persists, but LXDE and GDM does not, so it's most definitely KDM doing this.

Dan, ok, I found 2 cases that we should handle better,

In cases where kdm indeed still tries to use ~/.Xauthority , it does indeed use a write+rename to save it.

There's also a bug outlined in the past couple of comments where even if 
ForceUserAuthDir=true
is set, on logout, a ~/.Xauthority gets created for the sole (?) purpose of clearing all current/active auths, so it ends up being empty anyway.

And, if it wasn't clear, I'll definitely tackle fixing item 2, is 1 something that can be fixed via policy, or is there something I should be doing there too?

I'm a little new to using Redhat's bugzilla, but I'd really like to help out with this, if nothing else, testing fixes.  What should I be doing to get ready to help?

Rex, what is the name of the temporary file that is created for .Xauthority.  If the name is fixed, we can write policy for it.  For example.

.Xauthority.new or .Xauthority~

If it is random, then we won't be able to fix this as easily.

Dan, 
looks like the code appends "-n" for the temporary name, so ~/.Xauthority-n


Test builds on the way with an initial workaround patch for the latter item in comment #42 : 

f16: http://koji.fedoraproject.org/koji/buildinfo?buildID=280874

f15: http://koji.fedoraproject.org/koji/buildinfo?buildID=280875

<unuseful_comment>
nice to see some progress here, thanks!

- one would be a bit saddened looking at the upstream bugreport (except for the latest comments from Rex, btw nice filename in the patch :))
</unuseful_comment>

kdebase-workspace-4.6.5-8.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kdebase-workspace-4.6.5-8.fc15

kdebase-workspace-4.7.4-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kdebase-workspace-4.7.4-6.fc16

(In reply to comment #46)
> Dan, 
> looks like the code appends "-n" for the temporary name, so ~/.Xauthority-n
> 
> 
> Test builds on the way with an initial workaround patch for the latter item in
> comment #42 : 
> 
> f16: http://koji.fedoraproject.org/koji/buildinfo?buildID=280874
> 
> f15: http://koji.fedoraproject.org/koji/buildinfo?buildID=280875

Rex, I can verify that I've seen the ~/.Xauthority-n file before, I just can't remember how I triggered its creation.  I also recall seeing an ~/.Xauthority-l and ~/.Xauthority-c file and I'm unsure what/where/why that got created.  I also haven't seen it _lately_, so it could've been a hold-over from restoring my home directory from a backup or something.

I just applied the fixes from Rex's Koji build, and the problem appears to have disappeared.  ~/.Xauthority is no longer being created on logout.  i'm using kdm-4.7.4-6.fc16.x86_64, KDE as my desktop, and KDM as my greeter.   Works!

The only little iffy bit was when I installed the packages to begin with, and then went to init 3 and then init 5 to reload the KDM binary, I lost networking.  Reboot fixed it.  Not sure if it's related to the new packages or how I restarted KDM, but thought I'd put that out there.

Package kdebase-workspace-4.7.4-6.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kdebase-workspace-4.7.4-6.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0083/kdebase-workspace-4.7.4-6.fc16
then log in and leave karma (feedback).

~/.Xauthority-l and ~/.Xauthority-c file are used in locking the .Xauthority file. 

It is my experience that if .Xauthority is writable and a lock acquired then they get removed. They will be present when the .Xauthority file is not writable because of the problem discussed in this bug. If .Xauthority is not writable then those files will not be removed.

(In reply to comment #52)
> ~/.Xauthority-l and ~/.Xauthority-c file are used in locking the .Xauthority
> file. 
> 
> It is my experience that if .Xauthority is writable and a lock acquired then
> they get removed. They will be present when the .Xauthority file is not
> writable because of the problem discussed in this bug. If .Xauthority is not
> writable then those files will not be removed.

Thanks for the pro-tip John!

Also, I tested this on both my 32 and 64 bit systems, and everything seems to work correctly.  I added my Karma to the fix.

kdebase-workspace-4.7.4-6.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

kdebase-workspace-4.6.5-8.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.