When su from an xterm to another user, pam_xauth is supposed to set XAUTHORITY. However, this variable doesnt get propagated to the shell if su is simply executing the default shell. Reproducible: Always Steps to Reproduce: 1. Open an xterm, with pam_xauth enabled. 2. su 3. env Actual Results: (no XAUTHORITY) Expected Results: /root/.xauthxxxx However, all is fine when you do a su -c 'bash' I've found the problem: when you do a simple su without additional options, shadow-4.0.3/libmisc/shell.c handles it. Otherwise, if options are specified to be passed to the shell, shadow-4.0.3/src/su.c:762 is used. The problem lies in shadow-4.0.3/libmisc/shell.c using char **newenvp as the environment, instead of char **environ, which is being updated with variables from pam_open_session at shadow-4.0.3/src/su.c:689. A simple patch like this will solve the problem, but I am not sure if it is the cleanest solution: --- shadow-4.0.3/libmisc/shell.c.old 2003-07-15 21:56:05.000000000 +0800 +++ shadow-4.0.3/libmisc/shell.c 2003-07-15 22:04:54.000000000 +0800 @@ -39,6 +39,7 @@ extern char **newenvp; +extern char **environ; extern size_t newenvc; /* @@ -84,7 +85,7 @@ * grief. */ - execle (file, arg, (char *) 0, newenvp); + execle (file, arg, (char *) 0, environ); err = errno; /* Linux handles #! in the kernel, and bash doesn't make
Have you sent this patch upstream for consideration ?
No. Effects only become significant when shadow-4.0.3-su-pam_open_session.patch-v2 is applied. Otherwise only the setting of a safe IFS is non-functional. I would send a patch their way. The current fix is a quick hack to get my X applications working in su'ed terminals. :>
any news on this?
we need to get this in the tree.
Is it difficult to propagate this in the tree? Or is there a cleaner solution coming up?
Have anybody tried with shadow-4.0.7 ? From here it looks like XAUTHORITY at least is updated properly.
I've just installed gentoo stage3 using 2005.0 install cd. I think the problem is still there. When I did a "su - someuser -c somecommand", it fail to use what ever I've put in the "someuser" .bashrc or .bash_profile. I've describe the problem to my local gentoo group http://groups.yahoo.com/group/mygentoo/message/569
Nobody still have come back to my request to test with shadow-4.0.7-r<latest> (also would be nice to check it with pam-0.78-r2).
not sure what xterm with pam enabled meant (as my xterm doesn't link to pam and i wouldn't expect it to) but trying to replicate the problem using pam-0.78-r2 (2005.0/2005.1) failed as shown below : carenas@laptop ~ $ su - -c 'set | grep [X]AUTHORITY' Password: XAUTHORITY=/root/.xauthZFzHAV carenas@laptop ~ $ su - -c 'bash -c "set | grep [X]AUTHORITY"' Password: XAUTHORITY=/root/.xauthw8UMrG carenas@laptop ~ $ su - Password: laptop ~ # set | grep [X]AUTHORITY XAUTHORITY=/root/.xauthNzzO1q
It works well with pam-0.78-r4 and shadow-4.0.14-r1: martian@UFO ~ $ su - Password: UFO ~ # env|grep AUTH XAUTHORITY=/root/.xauthfsNQtH UFO ~ # emerge -pv pam shadow|grep -e pam -e shadow [ebuild R ] sys-libs/pam-0.78-r4 USE="berkdb -nis -pam_chroot -pam_console -pam_timestamp -pwdb" 0 kB [ebuild R ] sys-apps/shadow-4.0.14-r1 USE="nls pam -nousuid -skey" 0 kB And when downgraded to pam-0.78-r4 and shadow 4.0.14-r1 I can't reproduce that bug again: martian@UFO ~ $ su - Password: UFO ~ # env|grep AUTH XAUTHORITY=/root/.xauthAzxh7A UFO ~ # emerge -pv pam shadow|grep -e pam -e shadow [ebuild U ] sys-libs/pam-0.78-r4 [0.78-r2] USE="berkdb -nis -pam_chroot -pam_console -pam_timestamp -pwdb" 0 kB [ebuild U ] sys-apps/shadow-4.0.14-r1 [4.0.7-r4] USE="nls pam -nousuid -skey" 0 kB So everything is working well here.
Sorry, made a little mistake: "And when downgraded to pam-0.78-r4 and shadow 4.0.14-r1 I can't reproduce that bug again:" should be "And when downgraded to pam-0.78-r2 and shadow 4.0.7-r4 I can't reproduce that bug again:"
shadow-4.0.3 isn't in portage anymore, and all available versions (both stable and unstable) are working fine.
Can anyone still reproduce this bug?
*** Bug 14560 has been marked as a duplicate of this bug. ***
Seems like this either fixed itself or anyway it's worked around, closing until proven wrong.
