Bugzilla Bug 14560

Installed from 1.4rc2 
Have: 
shadow 4.0.3-r3 
pam 0.75-r11 
xfree 4.2.1-r2 
 
When I "su -" from my regular user account, pam_xauth creates what appears to be an 
intermediate temp file in /root, named .xauthXXXXX where XXXXX is some random 
string.  This file contains the necessary xauth cookie info.  However, this file is useless 
unless it is renamed to .Xauthority or the XAUTHORITY environment variable is set to 
point to this file, neither of which is happening.  When I exit the su session, this temp 
file is (correctly) deleted.

Works fine here.  Make sure you do not set XAUTHORITY in
.bashrc or .bash_profile ?

---------------------------------------------------
azarah@nosferatu gcc $ su -

KeyChain 2.0.1; http://www.gentoo.org/projects/keychain
 Copyright 2002 Gentoo Technologies, Inc.; Distributed under the GPL
 * Found existing ssh-agent at PID 4284

nosferatu root # cat /var/log/auth.log
Jan 27 03:50:42 nosferatu su(pam_unix)[19742]: session opened for user root by
(uid=500)
Jan 27 03:50:42 nosferatu su[19742]: pam_xauth: reading keys from
`/home/azarah/.Xauthority'
Jan 27 03:50:42 nosferatu su[19742]: pam_xauth: writing key `0100 000d
6e6f736665726174752e6c616e 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31
0010 d0c6b3e77f879ea5e798841530e9a3b5 ' to temporary file `/root/.xauthAokAqD'
nosferatu root # echo $XAUTHORITY
/root/.xauthAokAqD
nosferatu root # grep xauth /etc/pam.d/su
session    optional	/lib/security/pam_xauth.so debug
nosferatu root # 
------------------------------------------------------

The problem isn't that *I'M* setting XAUTHORITY anywhere.  The problem is that 
XAUTHORITY is not getting set anywhere by default. 
 
I've added xdm to the default runlevel, configured to start KDM from 3.1_rc6.  I log into 
a kde session from there.  My normal shell sessions do NOT have XAUTHORITY set; 
Xlib is obviously just using the default of $HOME/.Xauthority. 
 
After reading the patch for su, it became apparent that su only copies the 
XAUTHORITY variable if it is already set.  So if I export 
XAUTHORITY=$HOME/.Xauthority in my normal user shell, then "su -", XAUTHORITY 
gets set properly in the root shell.  If XAUTHORITY is unset in the user shell, then it 
does not get set by su or pam_xauth. 
 
This looks more like a bug somewhere in xfree/KDM? (for not setting XAUTHORITY in 
the first place?) 
 

Hmm, ok, missed that one.  Will have a look when I get the time ...

Any news on this? It seems sad that kdm doesn't work properly with pam / su.

I've tried to see how redhat make it work, but there are too many differences for me to see clearly :)

Any pointers on how we could try to sovle this?

On my system, the su works fine (i.e. pam sorts out X authentication) if I:-
- manually run startx into gnome or kde
- run gdm

but not if I:-
- run kdm
- run xdm

Well, as I stated in comment #2, if XAUTHORITY is set in the (non-root) shell 
before running su, then XAUTHORITY gets properly set in the root shell after 
running su.  So the simple workaround I did was just to add: 
 
# Work around XAUTHORITY bug 
export XAUTHORITY="$HOME/.Xauthority" 
 
in my ~/.bashrc. 

yes, indeed, that does it. thanks for the hint :)

From what I can see from xauth's source, is that it *should* set XAUTHORITY.
For some reason this do not happen though.

This is from my logs if the user I su'd from, did not have it set:

---------------------------------------------
Apr 29 22:36:33 nosferatu su(pam_unix)[581]: session opened for user root by (uid=500)
Apr 29 22:36:33 nosferatu su[581]: pam_xauth: reading keys from `/home/azarah/.Xauthority'
Apr 29 22:36:33 nosferatu su[581]: Add to env:  XAUTHORITY=/root/.xauthoyZup2
Apr 29 22:36:33 nosferatu su[581]: pam_xauth: writing key `0100 0009 6e6f73666572617475 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31 0010 9277b858a356a57937b82ed4b0739d2f ' to temporary file `/root/.xauthoyZup2'
nosferatu root # echo $XAUTHORITY

nosferatu root # 
-----------------------------------

Which basically comes down to:  It does 'set' it, but the way 
glibc/bash/whatever works, cause it not to get propagated if there was
no XAUTHORITY in the previous user's environment.

bug #24523 shows what's happening and includes a fix.

*** This bug has been marked as a duplicate of 24523 ***