Bug 65590 - The enviroment variable XAUTHORITY carries over su - username
Summary: The enviroment variable XAUTHORITY carries over su - username
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-05-28 05:12 UTC by Nathan G. Grennan
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-05-28 07:58:32 UTC
Embargoed:


Attachments (Terms of Use)

Description Nathan G. Grennan 2002-05-28 05:12:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.3 (X11; Linux i686; U;) Gecko/20020523

Description of problem:
I would like to be able to login as a normal user. Open a terminal window, su to
root, copy .Xauthority from the home directory of the user I logged in as to
another user, then su to that user and be able to run graphical programs.
Currently, $XAUTHORITY will = /home/<insert original username here>/.Xauthority
  Since the other user doesn't have access to the original user's home directory
this fails with permission denied. Even if the second user did have permission
to the directory .Xauthority's permissions are by default set to 600.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. init 5
2. Login as normal user
3. Open terminal window
4. su - root
5. cp -a /home/<insert original username here>/.Xauthority /home/<insert second
username here>
6. chown <insert second username here>.<insert second username here>
/home/<insert second username here>/.Xauthority
7. su - <insert second username here>
8. xterm
	

Actual Results:  Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

xterm Xt error: Can't open display: :0


Expected Results:  No error messages and xterm pops up

Additional info:

Comment 1 Mike A. Harris 2002-05-28 07:04:23 UTC
I don't see the usefulness of su'ing to root, and then su'ing to other
users accounts from there and running graphical programs.  At least not
as a remotely high priority thing.

I don't really consider this a bug, but more of a low priority feature
enhancement request.

Comment 2 Nathan G. Grennan 2002-05-28 07:33:32 UTC
I can understand why you might see it low priority. I found a better way to do
the same thing. I had tried something like it before, but not in exactly the
same way.  The manpage for xauth mentions
xauth extract - $DISPLAY | rsh otherhost xauth merge -

which can be redone as

xauth extract - $DISPLAY | ssh user@localhost /usr/X11R6/bin/xauth merge -


You run this as the first user and replace user with the username of the second
user. This will copy the hostname/unix:0 entry. It would probably be better if
it copied both, but it seems to work with just this one. The downside for me is
that I don't want to have to set a password for the second user(aka account only
accessiable by su - user  as root). The reason is that it is the code compiler
user(Thanks mharris for suggesting your rpmbuild-nonroot hack :) ) and so it
just makes security worse to give it a password. But even after using this more
direct method the XAUTHORITY environment variable is set wrong when you su -
user from the first user. In X I no of no other way to become another use than
su. Outside of X, using ctrl-alt-f1, login as second user, export DISPLAY=:0,
xterm  is too much hassle.

Comment 3 Nathan G. Grennan 2002-05-28 07:52:20 UTC
I thought of a simple workaround. I can add

XAUTHORITY=$HOME/.Xauthority
export XAUTHORITY

to ~/.bash_profile



Comment 4 Nathan G. Grennan 2002-05-28 07:54:44 UTC
The whole point of this is to avoid the the horribly insecure xhost +hostname if
the system has more than one person can login at a time.

Comment 5 Nathan G. Grennan 2002-05-28 07:58:26 UTC
The also could relate as a secure workaround for bugs like the one where you
must give root permission to your X session to be able to run Xcdroast from the
menu using consolehelper. The standard workaround is xhost +locahost, but as
mentioned above that is insecure.

Comment 6 Mike A. Harris 2002-08-08 02:50:20 UTC
Closing WONTFIX as I dont see any problem here.  If there is a problem,
it should be reported and fixed by XFree86.org on xpert
mailing list.  At a minimum, someone who understands xauthority information
a LOT more, needs to be a part of looking at this.

Making random uninformed changes to things is never good.




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