Failed X11 authentication does the wrong thing

[Darren Moffat]

>That's a fundamental limitation of the way ssh does forwarding of X 
>connections; it stores the authentication information in ~/.Xauthority,

I don't believe any of this has anything what so ever to do with the
X11 forwarding functionality of ssh since you get exactly the same behaviour
on a local login.

>and doing su - both changes the value of ~ and makes it impossible for
>you to read the file because it has to be readable only by the owner.

Not true at all, there is no enforcement of the permissions on the
.Xauthority file by xauth or anyone else that I know of and there are
no restrictions mentioned in the standard X11R6.4 man page for xauth.

As an example:

cube$ ssh -X borg
Enter passphrase for key '/home/djm/.ssh/id_rsa': 
Last login: Thu Jul 26 11:50:56 2001 from cube
borg$ ls -l ~/.Xauthority
-rw-------   1 darrenm  staff        453 Jul 26 11:50 
/home/darrenm/.Xauthority
borg$ chmod 644 ~/.Xauthority
borg$ su -
Password: 
# XAUTHORITY=/home/djm/.Xauthority
# export XAUTHORITY
# DISPLAY=borg:10.0
# export DISPLAY
# /usr/X/bin/xdpyinfo      
name of display:    borg:10.0
version number:    11.0
vendor string:    Sun Microsystems, In
...

I can also start an X client and it will display on braveheart.

Okay so this involves the user opening up the permissions on their
.Xauthority file to everyone if the users home directory is NFS mounted.
If it is local then root could read it anyway (at least on traditional unix
filesystems). You could use ACLs to give permission only to root (tricky
actually since you need to give the permission to nobody not root, and this
isn't really any better than giving world read).

I've also written a PAM module for use with su that uses xauth to
make a copy of the cookie for the current DISPLAY out of the src users
.Xauthority and put it into the destination users .Xauthority.  This a
safe way to do it - if I ever get the time I'll update the PAM module
to remove the cookie from the .Xauthority when the session exits.


>
>On Sat, Jul 21, 2001 at 01:34:50PM +0100, Matthew Vernon wrote:
>> Hi,
>> 
>> if I do the following:
>> 
>> ssh -X localhost
>> su - another_user
>> xterm
>> 
>> I get:
>> 
>> X connection to ming:10.0 broken (explicit kill or server shutdown).
>> 
>> Where what is really wanted was something like:
>> 
>> Xlib: connection to ":0.0" refused by server
>> Xlib: Client is not authorized to connect to Server
>> xterm Xt error: Can't open display: :0.0
>> 
>> 'tis easy to reproduce the bug, but the debug output that seems
>> relevant is:
>> debug1: X11 connection uses different authentication protocol.
>> 
>> I'm not sure I want to go hacking ssh'x X11 forwarding just yet (there
>> are more easy things to do first), so I thought I'd let you know.
>> 
>> Cheers,
>> 
>> Matthew
>> 
>> -- 
>> "At least you know where you are with Microsoft."
>> "True. I just wish I'd brought a paddle."
>> http://www.debian.org

--
Darren J Moffat