Description of problem: I just updated my system for the first time in a month or so and the "su -" command is not resetting the XAUTHORITY environment variable. When root, a "su - joeuser" leaves XAUTHORITY set to /root/.Xauthority. As a result, commands like: xauth extract - $DISPLAY | su -l --command="unset XAUTHORITY ; xauth merge -" joeuser Need to have the unset of XAUTHORITY or they will fail with: xauth: timeout in locking authority file /root/.Xauthority (the xauth merge produces this) I haven't changed the su command (sh-utils package), so I figure the problem is in glibc. Prior to this update I didn't have to unset XAUTHORITY for it to work. Version-Release number of selected component (if applicable): [root@mofo root]# rpm -q glibc glibc-2.2.4-32 [root@mofo root]# rpm -qf $(which su) sh-utils-2.0.11-5 [root@mofo root]# uname -a Linux mofo.meme.com 2.4.18-27.7.xsmp #1 SMP Fri Mar 14 05:52:30 EST 2003 i686 unknown How reproducible: Always. While root, "su - joeuser" then echo $XAUTHORITY Steps to Reproduce: While root, "su - joeuser" then echo $XAUTHORITY Actual results: /root/.Xauthority Expected results: /home/joeuser/.Xauthority Additional info: Note that .Xauthority cannot remain /root/.Xauthority because only root has any permissions on this file, so joeuser will never be able to use the screen.
see also Bug 83409 where I also raised this (and a couple other issues.)
glibc doesn't actively change the environment on its own except in SUID/SGID binaries it removes some variables glibc itself uses (not XAUTHORITY). The environment variable deletion better works, otherwise all kinds of things would break and there have been no reports like that. The problem must be somewhere else. I don't know who you think is responsible for removing the environment variable. I don't even know whether this is true. I do seee that going from a normal user to root the envvar is changed, but going from root to a normal user it isn't. No idea whether this is correct or not. I'll be closing this bug soon unless you can show it is really only updating glibc that caused the problem. I do not believe this for a second at this moment.
I can't say where the bug is, that's why I've sent it to you folks. Upgrading with errata did cause the problem, I su/XAUTHORITY every day, practically every hour, so I know it's upgrading that did it. But I didn't write into the original report all the packages I upgraded so I won't swear that it's glibc. I recall looking through the list of new rpms to try to figure out where to report it and glibc was the only candidate. None-the-less there's still a bug, reassign it to su if that makes you feel better. Maybe it's a problem in the way su intereacts with some other component. The change in behavior has the feel of some xdm/gdm configuration releated hackery, maybe it's in one of the base system config components somewhere. I always thought that it was login that cleared the env, excepting a few selected components. su - is supposed to do just like login. What use could it possibly be for XAUTHORITY to be cleared when going from a user to root, but not from root to a user? If anything it should be the other way around as root can read the user's file and not vice-versa, so when su-ing _from_ root you'd retain the ability to use the screen. I see no secure way to allow the reverse to be true. In any case, standard is better than better and su should retain it's traditional behavior. I submitted the bug so you folks could fix it, or at least report it to the right folks upstream for fixing. Or tell me that somebody smarter than I am knows that the Un*x specs have changed and there's new behavior for good reasons. If RH's going to ignore reproduceable oddities, especially subtle ones like this, I'm going to stop wasting my time reporting problems. It's usually clear what to do about the obvious problems, I only report them to you for the greater benefit of the community and in return for RH's software. If RH's not going to contribute it's expertice (as it must have done with the whole stupid backspace/delete xwindows/xterm/console/X/os keyboard mapping/configuration fiasco) to small but annoying problems I'll drop you from the loop. Which is not to say you _must_ fix this problem, but I at least expect some effort to dispatch the report upstream. On the good side, this is the first time in memory that upgrading broke something.
In an effort to get something going I'm assigning this to coreutils which contains su. There is not the slightest indication that this has anything to do with glibc.
Nalin: any idea what should happen here?
Tim, the intention is that joeuser can't access root's screen in the default configurations, per RHSA-2003:035. Placing "joeuser" in root's ~/.xauth/export file would change that to the previous behavior, which was deemed a security problem.
That settles it then. Be nice if the xauth man page had a see also to pam_xauth(8), if this hasn't already been done.
Please also add a note to the su(1) manpage, which is the first (and perhaps only) place most people will be looking. I got bit by this issue, and it took me quite a while to figure it out.
Suggest the words and where they should go, and I'll see about putting them in.
*** Bug 126300 has been marked as a duplicate of this bug. ***
*** Bug 150752 has been marked as a duplicate of this bug. ***
This is not a su but pam_xauth problem and it is fixed in current pam >= 0.79-9 (FC-4 updates, development).
And of course the X authority cookie cannot be exported from root to user because it would be a security problem. Also the hang when switching to root for second time is fixed.