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.
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
This is interesting. If I do 'rpm -V pam' as a normal user, I get this: [ianmacd@caliban ~]$ rpm -V pam ..?..... /sbin/pam_filter/upperLOWER But now look at this: [ianmacd@caliban ~]$ su - Password: [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 - Password: [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 #%PAM-1.0 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 nullok 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.
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.
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 500... 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 done 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.
[ianmacd@caliban ~]$ id -u 500 [ianmacd@caliban ~]$ su - Password: [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 systemuser=0 /etc/pam.d/kppp:session optional /lib/security/pam_xauth.so systemuser=0 /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 systemuser=0 /etc/pam.d/up2date:session optional /lib/security/pam_xauth.so systemuser=0 [root@caliban ~]#
Try just "su" instead of "su -"
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!
oops, that last entry was from me, tim.nl
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.
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, alone?
Fixed in sh-utils-2.0-2, which we'll put into RawHide in the next RawHide release. 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.