Red Hat Bugzilla – Bug 26343
after su, up2date unable to open display
Last modified: 2007-04-18 12:31:14 EDT
Logging in with gdm though not running a session manager, I get XAUTHORITY=/home/ejb/.Xauthority If I su and reset this environment variable to the same value, up2date fails with the following error: ------------------------------ Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server Traceback (innermost last): File "/usr/sbin/up2date", line 455, in ? main() File "/usr/sbin/up2date", line 441, in main import gui File "/usr/share/rhn/up2date/gui.py", line 16, in ? import gtk, GTK, GDK File "/usr/lib/python1.5/site-packages/gtk.py", line 29, in ? _gtk.gtk_init() RuntimeError: cannot open display ------------------------------ Note that running other X clients at this time works. I reported this along with other problems in a bug 26011 about printtool, but I'm reporting it again because it was not the primary focus of 26011. Running xhost localhost works around the problem but should not be necessary. Maybe the category of this bug should have python, python-gtk, or something like that.
Note: the same Xlib errors occur when I run up2date as myself and enter the root password when prompted. It was only after this failed that I tried running su first.
We (Red Hat) should really try to fix this before next release.
I've attempted to change the category of this bug to usermode since that seems to be where the problem is. /usr/bin/up2date is a link to consolehelper which in turn invokes /usr/sbin/up2date. If I su and invoke /usr/sbin/up2date, there is no display access problem. consolehelper (or userhelper) seems to reset all environment variables except HOME TERM DISPLAY SHELL USER LOGNAME PATH HOME TERM DISPLAY SHELL USER LOGNAME PATH The bug seems to be in userhelper.c. If my quick reading of the code is correct, it looks like the exec of the new process is done before XAUTHORITY is restored.
Okay -- I figured it out. Get rid of this line: session optional /lib/security/pam_xauth.so in /etc/pam.d/up2date and the problem is solved. This will need to be done for printconf-gui and any other X application that is linked to usermode.
sorry for all the noise.... I set the category back to up2date since that's the component that owns /etc/pam.d/up2date. More likely someone else will find this in a query.....
The real problem may be that pam_xauth doesn't work right. I'm going to stop babbling about this now. I just didn't want to leave things with the impression that I am suggesting that just removing the offending line from /etc/pam.d/up2date was necessarily the right fix. pam_xauth may have been there for a reason and may not be working. I noticed a while ago that my XAUTHORITY environment variable disappeared after su, but I did not suspect pam. I thought it was a feature of su. I don't think I have enough data to actually submit a bug report about pam_xauth though. Anyway, I trust that the person to whom this bug has been assigned will look at all the facts, understand what's happening and what's supposed to happen, and do the Right Thing. That's all I'm going to say today.
I'm unable to reproduce this with: gdm-2.0beta2-39 pam-0.74-3 up2date-2.1.7-2 up2date-gnome-2.1.7-2 usermode-1.37-2 My .Xclients file has been modified to simply "exec xterm". Logging in via gdm, I get an XAUTHORITY variable, but when I switch to another VT where I'm already logged in as root, remove root's .Xauthority file, and su from the X session, I can run both up2date and xclock without difficulty (though, as mentioned, the XAUTHORITY variable disappears). There *is* a problem in how unprivileged graphical apps are run (gnorpm-auth, when the user elects to run it unprivileged and XAUTHORITY doesn't point to ~/.Xauthority), and that'll be fixed in 1.40, but I can't reproduce the reported problem with either printtool or up2date.
can't duplicate it either...
I will send very explicit instructions on how to reproduce this problem and re-open unless it turns out to be a problem in my own environment. By explicit instructions, I mean, "create a user with the following home directory, boot at runlevel 3 with the following inittab, log in, type the following commands..."
Okay, I definitely know what the problem is. My uid is 417 which is <= 499 which is the systemuser parameter's value in pam_xauth. The problem I described would happen for any user with uid < 500. After being unable to reproduce this from a freshly created user created via useradd but being able to reproduce it every time from my own login even after replacing the entire contents of my home directory with the default user's, I finally traced it down to the uid, and found the argument systemuser to pam_xauth. If I add systemuser=299 to the pam_xauth line in /etc/pam.d/up2date, then it works for me too. I know useradd starts creating users with user ids of 500, but I've been creating users since long before RedHat existed and I have lots of users with IDs less than 500. Why does this value have to be so high? As it is now, I have a simple work-around: I can add the systemuser=299 argument to all pam.d files that have pam_xauth in them. I also have a heinous workaround: I can renumber all my uids on all my systems. I'd be really happy if there were a place I could change this globally other than editing pam_xauth.c to change the default value of this field. Anyway, I would understand if you weren't planning on fixing this, but I've reopened the bug so that this can receive some consideration. I've also changed severity to "low" and category to "pam".
*** Bug 26011 has been marked as a duplicate of this bug. ***
Nice catch. Historically, we've assigned new users UIDs starting at 500, but have had to make the area between 100 and 500 a "no man's land" for maximum compatibility with other OSs, which may assign users UIDs below 500. We'll change this default in pam_xauth for the next release. Thanks!