Summary: | pam_xauth creates temp file, but not .Xauthority | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ryan Koski <ryan> |
Component: | [OLD] Core system | Assignee: | PAM Gentoo Team (OBSOLETE) <pam-bugs+disabled> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | dharding, marko, mmacleod |
Priority: | High | ||
Version: | 1.4_rc2 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 24523 | ||
Bug Blocks: |
Description
Ryan Koski
2003-01-25 23:02:07 UTC
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. |