From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020227
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. su root
3. export HOME=/~user
Actual Results: X11 connection rejected because of wrong authentication.
Gdk-ERROR **: X connection to localhost:11.0 broken (explicit kill or server
Expected Results: apacheconf should start up.Gdk-ERROR **: X connection to
localhost:11.0 broken (explicit kill or server shutdown).
May be (vaguely) related to
The xterm isn't necessary, but it does verify that the authentication
cookies are properly available.
Somehow, or other, apacheconf seems to reset the HOME variable (or magically do
something to lose the authentication data).
This originally occured as a problem with starting apacheconf via sudo.
There seems to be a workaround using xauth..
( eval HOME=~$LOGNAME xauth nlist) | ( export HOME=~root; xauth nmerge - );
Well, ssh does xauth, but if you su or sudo to another user that user won't
inherit the authentication of the original user, resulting in a X11 forwarding
rejection, so this is rather a feature, not a bug. Or if it is a bug, then it's
more likely to be a sudo/su or ssh bug.
Read ya, Phil
Changing the HOME to the home of the original user
or: eval HOME=~$LOGNAME
(if you want to do it more generically)
will properly point the xauth information back to the proper location.
the ability to properly open an xterm window (see the Steps to Reproduce)
proves that the xauth information is properly accessible.
However: When apacheconf starts up, it forces xauth to grab the
authentication information from the WRONG PLACE!
NO OTHER X APP DOES THIS*, and I see no reason why apacheconf needs to do so.
(*at least -- no other *sane* app does this).
If you try my "Steps to Reproduce", you will be able to run
*but NOT apacheconf*
Why does apacheconf respond differently than xterm???
note: the reading of original-user xauth information is only possible if you are
SUing to root.
This is not an apacheconf bug
The comment about the xauth infomation was just an FYI (in afterthought, it's
probably better to describe it as a no-brainer comment).
The actual problem (as far as I can tell) is that apacheconf resets where it
gets it's xauth information from. (possibly by resetting HOME, or by setting
XAUTHORITY). In either case, it forces the user to place the X authority
information wherever Apacheconf thinks it should be, instead of being able to
tell apacheconf where
the authority information is.
Does this 7.2 system have the PAM and usermode errata packages applied?
Perhaps more importantly, does it have the openssh errata applied?
This should be fixed in pam-0.75-31 and later. (Sometimes there's a mismatch
between DISPLAY and the name used in the xauth file which causes "xauth list
$DISPLAY" to return nothing and not forward cookies properly. The newer package
works around this.)
As far as I can tell, we've installed all of the RPMs mentioned in
the errata page, and a relatively recent SSH version is installed....
# rpm -qa | egrep 'usermode|pam|openssh'
As far as I can tell, these are the latest and greatest RPMs.
I'm presuming that the reference to pan 75-31 is talking about future feleases
to pam .. not vurrent ones.
Created attachment 52306 [details]
This script address both 61524 and 62027 (double logging) by calling xauth and then post-editing httpd.conf