Bug 5509 - pam_xauth doesn't allow su root X connections
Summary: pam_xauth doesn't allow su root X connections
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sh-utils
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-10-04 20:15 UTC by Ian Macdonald
Modified: 2008-05-01 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-11-19 00:28:21 UTC

Attachments (Terms of Use)

Description Ian Macdonald 1999-10-04 20:15:04 UTC
The pam_xauth module in Red Hat 6.1 doesn't allow a user who
has just su'ed to root to run X applications. All such
attempts fail with a 'Permission denied' error.

Comment 1 Michael K. Johnson 1999-10-07 19:23:59 UTC
I cannot reproduce that.  Can you give me any more information
that might help me track down what's going on?   Can you cut
and paste the exact error message you are getting?  Also, please
rpm -V pam

Comment 2 Ian Macdonald 1999-10-07 19:46:59 UTC
This is interesting. If I do 'rpm -V pam' as a normal user, I get

[ianmacd@caliban ~]$ rpm -V pam
..?.....   /sbin/pam_filter/upperLOWER

But now look at this:

[ianmacd@caliban ~]$ su -
[root@caliban ~]# rpm -V pam
[root@caliban ~]#

That in itself seems strange to me.

Here is evidence of the problem as reported:

[ianmacd@caliban ~]$ su -
[root@caliban ~]# xeyes
Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: :0

/etc/pam.d/su contains:

[root@caliban ~]# cat /etc/pam.d/su
auth       required     /lib/security/pam_pwdb.so shadow nullok
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_cracklib.so
password   required     /lib/security/pam_pwdb.so shadow use_authtok
session    required     /lib/security/pam_pwdb.so
session    optional     /lib/security/pam_xauth.so

I'm using gdm to log in through X.

If you need any more information, just let me know.

Comment 3 Chris Siebenmann 1999-10-07 22:46:59 UTC
The default settings for pam_xauth.so assume that any user under
UID 500 (or so) should not have the magic Xauthority forwarding
done when you su from that user to root -- and it scrubs out any
$XAUTHORITY setting that user may have had in the process. This can
result in exactly this symptom.

 See 'man pam_xauth' for more details. One may wish to run it with
the 'debug' parameter, which is how I tracked down this locally.

(The 'rpm -V' failure is because the file in question isn't readable
by the person running the verification, so rpm can't check whether or
not the MD5 signature matches. Rather than print a potentially bogus
checksum-failed note, it marks the file as 'can't check this'.)

------- Additional Comments From   10/08/99 03:31 -------
According to the man page:

By default, pam_xauth will only forward keys when the root
user is the target user.

So, if you're right, the actual default behaviour is definitely at
odds with the man page description.

I'll try out the debugging option to the PAM module tonight when I'm
behind that machine again.

And I really should have twigged the '?' in the output to 'rpm -V'
when I ran it as a normal user.

Comment 4 Michael K. Johnson 1999-10-09 16:40:59 UTC
I just upgraded my home machine to 6.1, and the same thing happened
to me, the author of pam_xauth, because my user ID predates Red Hat
Linux (I like to test upgradability over long periods) and is below

While it is possible to edit all the /etc/pam.d/* files that call
pam_xauth to add a "systemuser=0" option, I'm thinking that for the
future I should add an /etc/security/xauth.conf that allows you to
set system defaults.

Here's a shell script segment that you can run in the /etc/pam.d
directory in order to fix this in the short term.

cd /etc/pam.d
for file in $(grep -l pam_xauth *) ; do
  sed '/pam_xauth/s/$/ systemuser=0/g' $file > foo.$$
  mv foo.$$ $file

Running that fixed the problem for me.  Let me know if it does
not do so for you.  If it doesn't fix it, please include the
output of
grep pam_xauth /etc/pam.d/*
in your message.

Comment 5 Ian Macdonald 1999-10-10 08:38:59 UTC
[ianmacd@caliban ~]$ id -u
[ianmacd@caliban ~]$ su -
[root@caliban ~]# xeyes
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: :0
[root@caliban ~]#

As you can see, my UID isn't below 500 (it is exactly 500) and it
still doesn't work, although the problem is no longer a lack of
permission, but an invalid MIT cookie.

Here's the grep output you requested:

[root@caliban ~]# grep pam_xauth /etc/pam.d/*
/etc/pam.d/gnorpm-auth:session    optional
/lib/security/pam_xauth.so systemuser=0
/etc/pam.d/kpackage:session    optional /lib/security/pam_xauth.so
/etc/pam.d/kppp:session    optional     /lib/security/pam_xauth.so
/etc/pam.d/rp3-config:session    optional
/lib/security/pam_xauth.so systemuser=0
/etc/pam.d/su:session    optional       /lib/security/pam_xauth.so
/etc/pam.d/up2date:session    optional  /lib/security/pam_xauth.so
[root@caliban ~]#

Comment 6 Wissmann, Klaus 1999-10-18 14:21:59 UTC
Try just "su" instead of "su -"

Comment 7 Ian Macdonald 1999-10-18 16:25:59 UTC
Yes, su without the '-' seems to do the trick, but is really not an
acceptable workaround.

'xhost localhost' is a little more convenient and no less secure on
this machine, but it still doesn't fix the problem in pam_xauth.

------- Additional Comments From   10/24/99 13:21 -------
i'd like to report that johnsonm's scriptlet to hack the files in
/etc/pam.d did the trick for me.  i had a UID under 500 and was
pulling my hair out trying to figure out why the file system check i
couldn't "su -c usernet" anymore.  after applying that script and
restarting X, everything was happy and behaving as normal.  and kppp
works now, too.  woo hoo!

Comment 8 Pickering, Timothy 1999-10-24 17:22:59 UTC
oops, that last entry was from me, tim.nl

Comment 9 Michael K. Johnson 1999-11-19 00:07:59 UTC
su is killing the DISPLAY variable when called with -
I'll have to fix that...

Might be a few other environment variables that should be kept
around, too.  I'll go think.

Comment 10 Chris Siebenmann 1999-11-19 00:12:59 UTC
I vaguely disagree. 'su -' is documented to scrub out all of
the environment variables except a few (and this is historical
behavior); changing this may surprise people who expect it to
follow the general practice. Perhaps su needs a new option,
something inbetween 'su -' and plain 'su', that cleans most
'dangerous' environment variables but leaves some, like $DISPLAY,

Comment 11 Michael K. Johnson 1999-11-19 00:28:59 UTC
Fixed in sh-utils-2.0-2, which we'll put into RawHide in the next RawHide

It most definitely is appropriate to export DISPLAY with su -, because it
is supposed to be a "login session", and a root login session under X
includes having DISPLAY set.

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