Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 14560 - pam_xauth creates temp file, but not .Xauthority
Summary: pam_xauth creates temp file, but not .Xauthority
Status: RESOLVED DUPLICATE of bug 24523
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: PAM Gentoo Team (OBSOLETE)
Depends on: 24523
  Show dependency tree
Reported: 2003-01-25 23:02 UTC by Ryan Koski
Modified: 2006-04-21 08:24 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Koski 2003-01-25 23:02:07 UTC
Installed from 1.4rc2 
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.
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2003-01-26 20:51:29 UTC
Works fine here.  Make sure you do not set XAUTHORITY in
.bashrc or .bash_profile ?

azarah@nosferatu gcc $ su -

KeyChain 2.0.1;
 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
Jan 27 03:50:42 nosferatu su[19742]: pam_xauth: reading keys from
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
nosferatu root # grep xauth /etc/pam.d/su
session    optional	/lib/security/ debug
nosferatu root # 
Comment 2 Ryan Koski 2003-01-26 23:43:30 UTC
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?) 
Comment 3 Martin Schlemmer (RETIRED) gentoo-dev 2003-01-28 15:13:56 UTC
Hmm, ok, missed that one.  Will have a look when I get the time ...
Comment 4 Marko Daniel 2003-04-28 22:02:23 UTC
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
Comment 5 Ryan Koski 2003-04-29 01:16:46 UTC
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. 
Comment 6 Marko Daniel 2003-04-29 10:17:35 UTC
yes, indeed, that does it. thanks for the hint :)
Comment 7 Martin Schlemmer (RETIRED) gentoo-dev 2003-04-29 16:40:42 UTC
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.
Comment 8 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2004-08-12 01:18:36 UTC
bug #24523 shows what's happening and includes a fix.
Comment 9 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-04-21 08:24:15 UTC

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