Bug 87598 - XAUTHORITY env var not reset on 'su -'
XAUTHORITY env var not reset on 'su -'
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
:
: 126300 150752 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-29 16:48 EST by kop
Modified: 2007-04-18 12:52 EDT (History)
5 users (show)

See Also:
Fixed In Version: pam-0.79-9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-09 06:01:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kop 2003-03-29 16:48:57 EST
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.
Comment 1 Robert Tinsley 2003-04-05 11:45:28 EST
see also Bug 83409 where I also raised this (and a couple other issues.)
Comment 2 Ulrich Drepper 2003-10-03 17:33:16 EDT
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.
Comment 3 kop 2003-10-06 21:23:42 EDT
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.
Comment 4 Ulrich Drepper 2003-11-05 14:26:50 EST
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.
Comment 5 Tim Waugh 2003-11-06 08:33:10 EST
Nalin: any idea what should happen here?
Comment 6 Nalin Dahyabhai 2004-06-18 15:23:07 EDT
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.
Comment 7 kop 2004-06-18 16:45:17 EDT
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.
Comment 8 redhat-bugs2eran 2004-09-25 19:38:30 EDT
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.
Comment 9 Tim Waugh 2004-12-07 12:40:31 EST
Suggest the words and where they should go, and I'll see about putting them in.
Comment 10 Tim Waugh 2004-12-08 11:23:07 EST
*** Bug 126300 has been marked as a duplicate of this bug. ***
Comment 11 Tim Waugh 2005-04-11 07:26:01 EDT
*** Bug 150752 has been marked as a duplicate of this bug. ***
Comment 12 Tomas Mraz 2005-09-09 06:01:08 EDT
This is not a su but pam_xauth problem and it is fixed in current pam >= 0.79-9
(FC-4 updates, development).
Comment 13 Tomas Mraz 2005-09-09 06:04:19 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.