Bug 61524 - apacheconf X11 authentication violation when starting under ssh -> su or sudo (xauth confused)
apacheconf X11 authentication violation when starting under ssh -> su or sudo...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: usermode (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks: 61590
  Show dependency treegraph
 
Reported: 2002-03-20 17:34 EST by Stephen Samuel
Modified: 2007-04-18 12:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-28 18:36:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This script address both 61524 and 62027 (double logging) by calling xauth and then post-editing httpd.conf (1.31 KB, application/x-sh)
2002-04-05 01:24 EST, Stephen Samuel
no flags Details

  None (edit)
Description Stephen Samuel 2002-03-20 17:34:32 EST
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.
Comment 1 Stephen Samuel 2002-03-20 18:48:36 EST
There seems to be a workaround using xauth..

( eval HOME=~$LOGNAME xauth nlist) | ( export HOME=~root; xauth nmerge  - );
apacheconf 

guh!
Comment 2 Phil Knirsch 2002-03-26 04:34:30 EST
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
Comment 3 Stephen Samuel 2002-03-26 14:19:15 EST
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???
Comment 4 Stephen Samuel 2002-03-26 14:24:40 EST
note: the reading of original-user xauth information is only possible if you are
SUing to root.
Comment 5 Jonathan Blandford 2002-03-27 11:20:36 EST
This is not an apacheconf bug
Comment 6 Stephen Samuel 2002-03-27 20:08:04 EST
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.
Comment 7 Nalin Dahyabhai 2002-03-28 17:36:08 EST
Does this 7.2 system have the PAM and usermode errata packages applied?
Comment 8 Nalin Dahyabhai 2002-03-28 18:36:21 EST
Perhaps more importantly, does it have the openssh errata applied?
Comment 9 Nalin Dahyabhai 2002-03-28 19:18:52 EST
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.)
Comment 10 Stephen Samuel 2002-03-29 13:40:17 EST
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.
Comment 11 Stephen Samuel 2002-04-05 01:24:04 EST
Created attachment 52306 [details]
This script address  both 61524 and 62027 (double logging) by calling xauth and then  post-editing httpd.conf

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