Bug 61524 - apacheconf X11 authentication violation when starting under ssh -> su or sudo (xauth confused)
Summary: apacheconf X11 authentication violation when starting under ssh -> su or sudo...
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: usermode   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 61590
TreeView+ depends on / blocked
 
Reported: 2002-03-20 22:34 UTC by Stephen Samuel
Modified: 2007-04-18 16:41 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-28 23:36:26 UTC
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 06:24 UTC, Stephen Samuel
no flags Details

Description Stephen Samuel 2002-03-20 22:34:32 UTC
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 23:48:36 UTC
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 09:34:30 UTC
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 19:19:15 UTC
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 19:24:40 UTC
note: the reading of original-user xauth information is only possible if you are
SUing to root.

Comment 5 Jonathan Blandford 2002-03-27 16:20:36 UTC
This is not an apacheconf bug

Comment 6 Stephen Samuel 2002-03-28 01:08:04 UTC
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 22:36:08 UTC
Does this 7.2 system have the PAM and usermode errata packages applied?

Comment 8 Nalin Dahyabhai 2002-03-28 23:36:21 UTC
Perhaps more importantly, does it have the openssh errata applied?

Comment 9 Nalin Dahyabhai 2002-03-29 00:18:52 UTC
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 18:40:17 UTC
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 06:24:04 UTC
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.