Re: can't run editor when su... why?

[Jesse Evans <jpjevans@earthlink.net>]

Hi, folks

	Thanks for the info... so far, the method (for root) described
below from TA seems to be the simplest.

	Now, is there a way to automate this? I tried adding the
follwing lines to root's .bashrc:

XAUTHORITY=./.Xauthority
DISPLAY=:0.0
export XAUTHORITY DISPLAY

	but this only works if I su from the original user's home
directory. (Otherwise, './' does not point to the right place.)

	What I need to know is how to determine the home directory of
the user who ran startx so that information can be built into the 'XAUTHORITY='
statement. 


	Also, I just want to say that over the past couple of months I've been
getting some great answers from this list to my questions. Thanks to all of
you have have been of help so far!

	And, TIA for this one.

'til next we type
HAVE FUN!! -=- Jesse

> The problem is that "you" own the X session, "root" doesn't.
> 
> The easiest way to get this to work is to type
> 
>    xhost + localhost
> 
> before you do your su.  This means that you'll let anyone
> from the host "localhost" (ie, your computer) connect to your
> X.
> 
> However, I recall there were some security risks associated with
> using xhost like this... maybe someone else will point them out.

Ok, I will.  If you do that, ANYONE on the hosts added can capture keys, 
dump your window, and virtually hijack your computer completely.

> If you aren't connected to a network (or just dial up occasionally
> using, eg, ppp) then you should have no problems.  (Using
> "xhost + localhost" helps, lots of people just use "xhost +",
> which allows *anyone* from *anywhere* access -- bad idea.)

I really think there is no reason to *ever* do "xhost + anything".

First, Tcl's "send" command will not operate if xhost security is
allowed at all.  That would break things like exmh which use send to
talk to a background process.  Tcl disables "send" when "xhost +" is
used because it would otherwise allow simple control of *everything*
(send combined with exec).

While "send" is not a security issue when "xhost +" is used, you lose
functionality, even if you never ever connect to any other computer.

The other reason not to ever run "xhost +" is because there are better
ways to share your X session.  For root, it is extremely easy.  For
other users, it's a little more tricky:

For root:

root# XAUTHORITY=/home/your_id/.Xauthority
root# DISPLAY=:0.0
root# export XAUTHORITY DISPLAY

"your_id" is the id of whoever ran "startx".

For NON-root users:

You can use "xauth" to extract the key from one user and to add the key
to the other.  The tricky part is in keeping it secure in the meantime.
Encrypting with pgp is one possibility.

To extract a key:

user1% xauth extract my_key $DISPLAY

The file my_key has your key in it (xauth SHOULD create it with user rw
permissions only).  Do whatever you need to to securely transfer it to
the other user, and then have that user run:

user2% xauth merge my_key
user2% DISPLAY=:0.0
user2% export DISPLAY

Note that user2 now has complete control to your X session until you end
it and start a new one (at which time a new key will be generated).  If
user1 is running any Tcl application which has send enabled (default),
user2 can tell that Tcl application to exec arbitrary commands and
return the results to user2.  There is also nothing prohibiting user2
from giving the key to user3!  You wouldn't want to do this to someone
you didn't trust.

As far as I know, you can't change the xauth key during a session.
Still, this is far better than giving unlimited users access to your X
session.

Finally, your keys are stored in ~/.Xauthority, so make sure you don't
give global access to it.

rgds-- TA  (tallard@frb.gov)
I don't speak for the Federal Reserve Board, it doesn't speak for me.


-- 
Unsubscribe?  mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null

-- 
'til next we type...
HAVE FUN!! -- Jesse