X11 forwards and libwrap support

[Dan Astoorian]

On Wed, 14 Nov 2001 11:08:04 EST, Nicolas Williams writes:
> 
> Hmmm, is it because .Xauthority files are stored in home directories
> shared across multiple hosts?
> 
> If so, why not mkstemp() a new .Xauthority file, shove the cookie there
> and set XAUTHORITY to point to it?

This isn't directly related, but this has reminded me about another
minor problem I've been meaning to mention involving .Xauthority files
over NFS.

Since xauth copies the contents of the .Xauthority file and unlinks the
old one, this can result in a stale NFS file handle when X clients try
to access $HOME/.Xauthority shortly after sshd on a remote machine has
called xauth to add a cookie.

A contrived example, which others may or may not be able to reproduce:

palm.cs:~> setenv DISPLAY palm.cs:0.0
palm.cs:~> ssh -X -f otherhost xterm ; sleep 3 ; xterm
Xlib: connection to "palm.cs:0.0" refused by server
Xlib: Client is not authorized to connect to Server
xterm Xt error: Can't open display: palm.cs:0.0
palm.cs:~> 

The Xlib errors above are from the local xterm, because
$HOME/.Xauthority becomes a stale NFS handle after ssh runs xauth to set
up the cookie for the X forwarding.  The problem only persists for a
short time.

I've seen this issue cause problems when users have put ssh commands
into their X startup files; e.g., when they try to log into X, the
window manager fails to start up due to the stale NFS handle caused by
an ssh command to a compute server, and so the user gets logged out
immediately.

This type of symptom, IF it occurs, is usually intermittent.  Back when
OpenSSH kept its cookies in /tmp, it wasn't an issue; now that they're
back to the default location, some of my users have started seeing it
again.

In case anyone else has run into this, one workaround is to set
XAUTHORITY in $HOME/.ssh/environment (e.g.,
"XAUTHORITY=/path/to/homedir/.ssh/Xauthority") so that ssh cookies for X
forwardings are kept in a separate .Xauthority file from other xauth
cookies (which probably isn't a bad idea anyway).

I don't think this is by any means a showstopper, but does anyone think
it would be worthwhile for OpenSSH's daemon to use a non-default
location for its cookies by setting $XAUTHORITY to point to a file under
$HOME/.ssh/?

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican