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 -"
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
[root@mofo root]# rpm -qf $(which su)
[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
While root, "su - joeuser" then echo $XAUTHORITY
Steps to Reproduce:
While root, "su - joeuser" then echo $XAUTHORITY
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.