Logging in with gdm though not running a session manager, I get
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 ?
File "/usr/sbin/up2date", line 441, in main
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 ?
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
Maybe the category of this bug should have python, python-gtk, or something
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
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
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
Okay -- I figured it out. Get rid of this line:
session optional /lib/security/pam_xauth.so
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
I'm unable to reproduce this with:
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
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.