🚀 go-pugleaf

In article <mferrare.679129467@adelphi.physics.adelaide.edu.au>, mferrare@physics.adelaide.edu.au (Mark Ferraretto) writes:

> Client is called pietro.
> Server is called flare.
> Both need to go to the nameserver to find the other's name

> on flare:
> 	xhost pietro
> pietro being added to access control list

> on pietro
> 	setenv DISPLAY flare.physics.adelaide.edu.au:0
> 	xludwig
> Xlib:  connection to "flare.physics.adelaide.edu.au:0.0" refused by server
> Xlib:  Client is not authorized to connect to Server
> Couldn't open display "flare.physics.adelaide.edu.au:0"

You need some background information to understand this.  First, note
that the list of permitted hosts is actually a list of addresses, not
names.

Then, I conjecture that pietro is multi-homed: that it has multiple
addresses.  I further conjecture that flare's xhost binary was compiled
with an old <netdb.h>, one without the h_addr_list[] array, or perhaps
the xhost source itself was sufficiently old it didn't know about it
(is this possible? is xhost that old?).

Why does this explain it?  Rather complicated to explain cold; let's
try an example:

flare is, let us say, 123.45.67.8; pietro is 123.45.68.1 and
123.45.67.9, with the nameserver returning the address in that order.

Then xhost does a gethostbyname("pietro") [roughly - don't pick nits
please!].  It gets back a struct hostent containing just the first
address - 123.45.68.1.  It adds this to the list of allowed hosts.  But
then the incoming connection when you start up an X application comes
from the "near" side, which is the other address, the one that *wasn't*
added.

As a workaround, you could use xhost +123.45.67.9 (err, substitute
pietro's actual address, of course!).  A better fix would be to update
your xhost source, if necessary, and rebuild it with proper
fully-resolver-aware include files.

If this isn't it I don't know what's wrong; I'd have to investigate
further.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu