Bug 26343 - after su, up2date unable to open display
after su, up2date unable to open display
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Preston Brown
Aaron Brown
Florence Gold
: 26011 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-02-06 13:56 EST by Jay Berkenbilt
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-12 14:05:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jay Berkenbilt 2001-02-06 13:56:46 EST
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
    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 ?
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
like that.
Comment 1 Jay Berkenbilt 2001-02-06 14:07:33 EST
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
Comment 2 Glen Foster 2001-02-06 19:19:51 EST
We (Red Hat) should really try to fix this before next release.
Comment 3 Jay Berkenbilt 2001-02-06 22:39:36 EST
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


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
Comment 4 Jay Berkenbilt 2001-02-06 23:46:37 EST
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.
Comment 5 Jay Berkenbilt 2001-02-06 23:51:20 EST
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.....
Comment 6 Jay Berkenbilt 2001-02-07 00:12:56 EST
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.
Comment 7 Nalin Dahyabhai 2001-02-08 00:51:55 EST
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.
Comment 8 Preston Brown 2001-02-08 22:35:19 EST
can't duplicate it either...
Comment 9 Jay Berkenbilt 2001-02-09 10:37:39 EST
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..."
Comment 10 Jay Berkenbilt 2001-02-11 02:17:16 EST
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".
Comment 11 Nalin Dahyabhai 2001-02-12 14:05:37 EST
*** Bug 26011 has been marked as a duplicate of this bug. ***
Comment 12 Nalin Dahyabhai 2001-02-12 15:18:40 EST
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.


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