Status of Bugzilla #1153

[Simon Vallet]

On Tue, 21 Feb 2006 07:12:49 +1100
Darren Tucker <dtucker at zip.com.au> wrote:

> On Mon, Feb 20, 2006 at 03:49:23PM +0100, Simon Vallet wrote:
> > I'd like to know if there is any chance to get bug 1153 fixed
> > soon ? It seems like a trivial issue, a patch is provided, and it's a
> > pain for us to manually patch every new release -- this was reported
> > as a portable-specific bug, but also affects vanilla openssh.
> 
> Well, you haven't explained why it's a bug and should be changed.  Under
> what circumstances is a $DISPLAY of the hostname not the "wanted value"?

OK -- we have globally the following setup here : an external ssh
gateway performing X11 forwarding to the internal network -- as this
machine is multihomed, a call to gethostname() returns (correctly IMO)
the short name of the gateway, which is the value used to set DISPLAY
and to add xauth credentials. 

When called, xauth (correctly) qualifies the host name to the one which
resolves to the externally reachable interface of the gateway. DISPLAY,
however, is still unqualified.

Once on the gateway, if an external user wants to get an X11 client
running on an internal machine in an automated way (i.e. without
connectiong to the target machine and manually set DISPLAY), it will
use the value of DISPLAY set by OpenSSH, which uses the unqualified
hostname. When qualifying this hostname, X11 will use the default
domain, which is the one from the internal network.

And this is were the problem appears : as xauth credentials
are set using the FQDN of the external interface of the gateway, any
internal X11 client will be denied access to the forwarded X11 server.

Not using gethostname() but the connected IP to set DISPLAY solves this
qualified/unqualified hostname issue, and is IMO the correct behaviour,
considering that I otherwise fail to see how to always choose the
working hostname on a multihomed machine.

Simon