The version of su installed from the shadow package (shadow-4.0.3) never calls the pam_open_session function. This means that the session entries in /etc/pam.d/su never get executed. In particular, the pam_xauth module cannot be used to transfer the X privileges of the current user to root when using su.
i noticed the critial marking on this bug. im afraid i wont be able to get to it, until at least this weekend. if yuo guys can wait until then, i'll look into it. if not, then please look into it and make suggestion or have somebody else look into it. if you have a patch, i could include it immediately. but like i say, if nobody says anything, i'll get into it this weekend. yuo might want to look at redhat/mandrake's su util and what it looks like, etc. thats all or now, gotta run...
hmm, yeah i know whats going on. should have a fix soon as this thanksgiving *gobble* *gobble* stuff calms down ;-)
Created attachment 4816 [details, diff] shadow-4.0.3-su-pam_open_session.patch Chip, I know you wanted to do the sh-utils thing, but I thought this will be easier, and we can get it fixed in shadow, which is not the case with sh-utils. Anyhow, this patch add pam_open_session() to su, which should fix this problem. Try shadow-4.0.3-r1 and let me know.
Updated the patch to also call pam_close_session, and use the correct XAUTHORITY. Please try shadow-4.0.3-r2.
this doesnt seem to be working for me :/
Allah kazam ... it should be working now for you ...
az: user woodchip is in group wheel (not that it matters :/) he uses su to goto user root. (in an xterm btw..) then user root tries to run X program: error, not authorized to connect. or thereabouts, going from memory. i notice there is no ~/.xauth/ getting created as some docs seem to say it will. show me what you're doing to test this, i guess im on crack..
azarah@nosferatu azarah $ 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 6355 nosferatu root # set | awk '$0~/XAUTH|DISPLAY/ {print $0}' DISPLAY=:0 XAUTHORITY=/root/.xauthqYR3uG nosferatu root # cat /etc/pam.d/su #%PAM-1.0 auth sufficient /lib/security/pam_rootok.so auth sufficient /lib/security/pam_wheel.so use_uid trust auth required /lib/security/pam_wheel.so use_uid group=wheel auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_userdb.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_xauth.so debug nosferatu root # tail /var/log/auth.log Nov 3 11:47:00 nosferatu su[21565]: pam_xauth: reading keys from `/home/azarah/.Xauthority' Nov 3 11:47:00 nosferatu su[21565]: pam_xauth: writing key `0100 000d 6e6f736665726174752e6c616e 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31 0010 6663a3e135d0f0ff1e9bc9e3dc0d5d7a ' to temporary file `/root/.xauth7FjFSr' Nov 3 11:48:46 nosferatu su(pam_unix)[21565]: session closed for user root Nov 3 11:48:46 nosferatu su[21565]: pam_xauth: removing `/root/.xauth7FjFSr' Nov 3 11:48:48 nosferatu su[21614]: PAM unable to dlopen(/lib/security/pam_userdb.so) Nov 3 11:48:48 nosferatu su[21614]: PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: __db_ndbm_open] Nov 3 11:48:48 nosferatu su[21614]: PAM adding faulty module: /lib/security/pam_userdb.so Nov 3 11:48:48 nosferatu su(pam_unix)[21614]: session opened for user root by (uid=500) Nov 3 11:48:48 nosferatu su[21614]: pam_xauth: reading keys from `/home/azarah/.Xauthority' Nov 3 11:48:48 nosferatu su[21614]: pam_xauth: writing key `0100 000d 6e6f736665726174752e6c616e 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31 0010 6663a3e135d0f0ff1e9bc9e3dc0d5d7a ' to temporary file `/root/.xauthqYR3uG' nosferatu root # epm -qG shadow sys-apps/shadow-4.0.3-r2 nosferatu root #
Hrm, I see pam_pwdb.so link against the wrong libdb :/
pam_userdb even. Added pam-0.75-pam_userdb-use-db3.patch which should fix this.
doesnt work with vnc but works locally. who knew? ;)
Hello Not sure if it's acceptable to post additional comments here now that the bug is officially closed, but I for one am still having a problem. When I start X using the startx command from a VC, su works as desired: an xauthority file (.xauthFOO) is created in /root/ and the environment is updated accordingly: # env|grep XAUTHORITY shows that the variable points to .xauthFOO However, if I log on using kdm, the xauthority file is also created but the environment is *not* updated and, say, xclock dies with:- Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Error: Can't open display: :0.0 Is this another version of this bug or have I got a setting wrong somewhere? All the best okram Any ideas?
If you dont specify the -l (or whatever) flag to konsole to tell it it should be a login shell, DISPLAY are not exported, and thus pam_xauth do not do its thing.
I don't think that's the problem here. When I use startx to launch kde: yo@rojo yo $ ls -ld .[xX]* -rw------- 1 yo users 98 Dec 20 12:32 .Xauthority drwx------ 2 yo users 4096 Dec 11 09:37 .xcin -rw-r--r-- 1 yo users 9 Dec 19 13:08 .xinitrc drwxr-xr-x 4 yo users 4096 Dec 19 15:19 .xmms -rw------- 1 yo users 983 Dec 19 12:55 .xsession-errors -rw------- 1 yo users 366 Dec 18 15:20 .xsmsiA6MD yo@rojo yo $ xauth list rojo/unix:0 MIT-MAGIC-COOKIE-1 foofoofoofoofoofoofoo... rojo.localdomain:0 MIT-MAGIC-COOKIE-1 foofoofoofoofoofoofoo... yo@rojo yo $ su - Password: rojo root # xauth list rojo/unix:0 MIT-MAGIC-COOKIE-1 foofoofoofoofoofoofoo... rojo root # ls -ld .[xX]* -rw-r--r-- 1 root root 0 Dec 20 12:31 .Xauthority -rw------- 1 root root 49 Dec 20 12:25 .xauthsQfvWn -rw------- 1 root root 9847 Dec 19 12:16 .xsession-errors rojo root # env | grep -e "DISPLAY\|XAUTHORITY" DISPLAY=:0.0 XAUTHORITY=/root/.xauthsQfvWn rojo root # Whe I log in using kdm: yo@rojo yo $ ls -ld .[xX]* -rw------- 1 yo users 147 Dec 20 13:14 .Xauthority drwx------ 2 yo users 4096 Dec 11 09:37 .xcin -rw-r--r-- 1 yo users 9 Dec 19 13:08 .xinitrc drwxr-xr-x 4 yo users 4096 Dec 19 15:19 .xmms -rw------- 1 yo users 864 Dec 20 13:15 .xsession-errors -rw------- 1 yo users 366 Dec 18 15:20 .xsmsiA6MD yo@rojo yo $ xauth list rojo.localdomain:0 MIT-MAGIC-COOKIE-1 foobarfoobarfoobarfoobarfoobarfo 61-216-26-216.HINET-IP.hinet.net:0 MIT-MAGIC-COOKIE-1 foobarfoobarfoobarfoobarfoobarfo rojo/unix:0 MIT-MAGIC-COOKIE-1 foobarfoobarfoobarfoobarfoobarfo --- NB: I don't understand why there is now an entry for my pppoe dialup server host name. X is started with -nolisten tcp and only cups is listening: yo@rojo yo $ netstat --protocol=inet -l -n Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN udp 0 0 0.0.0.0:631 0.0.0.0:* yo@rojo yo $ su - Password: rojo root # xauth list rojo root # ls -ld .[xX]* -rw-r--r-- 1 root root 0 Dec 20 12:31 .Xauthority -rw------- 1 root root 49 Dec 20 13:20 .xauth7CQCrQ -rw------- 1 root root 9847 Dec 19 12:16 .xsession-errors rojo root # env | grep -e "DISPLAY\|XAUTHORITY" DISPLAY=:0.0 rojo root # In other words, I am using login shells. The xauthority MIT-cookie is passed on. The display variable is set. But the xauthority variable is NOT set. rojo root # xclock Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Error: Can't open display: :0.0 rojo root # xauth -f .xauth7CQCrQ list rojo/unix:0 MIT-MAGIC-COOKIE-1 foobarfoobarfoobarfoobarfoobarfo rojo root # export XAUTHORITY=.xauth7CQCrQ rojo root # xclock rojo root # To summarise: Everything works perfectly as expected and desired when I use startx. When I use kdm, the following are odd/different/not as expected or desired: 1) It takes a long time for the login window to come up 2) There is an additional xauth entry for my dynamically allocated IP address even though X is not listening on tcp at all 3) The MIT cookie is passed on to root, but the XAUTHORITY variable is not set to the corresponding temporary .xauthfoobar file.
