Red Hat Bugzilla – Bug 61524
apacheconf X11 authentication violation when starting under ssh -> su or sudo (xauth confused)
Last modified: 2007-04-18 12:41:02 EDT
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): How reproducible: Always Steps to Reproduce: 1.ssh user@remotehost 2. su root 3. export HOME=/~user 4. xterm 5. apacheconf. Actual Results: X11 connection rejected because of wrong authentication. Gdk-ERROR **: X connection to localhost:11.0 broken (explicit kill or server shutdown). Expected Results: apacheconf should start up.Gdk-ERROR **: X connection to localhost:11.0 broken (explicit kill or server shutdown). Additional info: May be (vaguely) related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=28351 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 - ); apacheconf guh!
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 export HOME=~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 xterm xclock civ (freeciv) *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' pam_krb5-1.31-1 pam-0.75-18.7 usermode-1.46-1 openssh-askpass-3.1p1-1 openssh-server-3.1p1-1 pam-devel-0.75-18.7 openssh-3.1p1-1 openssh-clients-3.1p1-1 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