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 ***
