Amaury Forgeot d'Arc writes:

if family == 'AF_INET': - return ('localhost', 0) + return ('', 0) elif family == 'AF_UNIX': return tempfile.mktemp(prefix='listener-', dir=get_temp_dir()) elif family == 'AF_PIPE':

Doesn't it have important security implications?

On Wed, Jun 18, 2008 at 1:51 PM, Antoine Pitrou wrote:

Amaury Forgeot d'Arc writes:

...

OK, I am not a tcp expert. How about the following patch? It seems to me that it is wrong for the server to lie about the address it listens to.

Maybe I'm missing something but... if the client part defaults to connecting to "localhost" in TCP mode, why doesn't the server part also default to listening on "localhost" in TCP mode? Having different address detection algorithms on both ends sounds like a recipe for bugs like this.

In any case, perhaps one should ask guidance to the original author before making important changes like this one.

The server component *is* listening to localhost by default. The client in the code I pasted has the server's .address attribute passed into it to tell the client where to connect to. -jesse

On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou wrote:

Jesse Noller writes:

...

The server component *is* listening to localhost by default. The client in the code I pasted has the server's .address attribute passed into it to tell the client where to connect to.

So I take it that the .address attribute is different from "localhost", but why? Is there any point in trying to be clever here?

No, it is *not* different than localhost - it *is* localhost as that is the object.address of the server.

Amaury Forgeot d'Arc wrote:

2008/6/18 Jesse Noller :

...

On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou wrote:

...

Jesse Noller writes:

...

The server component *is* listening to localhost by default. The client in the code I pasted has the server's .address attribute passed into it to tell the client where to connect to. So I take it that the .address attribute is different from "localhost", but why? Is there any point in trying to be clever here? No, it is *not* different than localhost - it *is* localhost as that is the object.address of the server.

Well, on my win2k machine getfqdn('127.0.0.1') returns the actual name of the machine. This is the name that was stored in server.address. Hence my patch that simply remove the call to getfqdn.

Point of interest: I was involved in developing an application where we gave up on trying to persuade getfqdn() to return reliable results on Windows machines - regardless of which local network interface you use to do the lookup, Windows 2k3 is likely to return an answer of 'computername.computerdomain' without bothering to consult the local DNS server (annoyingly, it used to do this right on previous Windows versions). So I'm inclined to consider any code which expects a useful answer out of getfqdn() to be non-portable at best and outright broken at worst. We worked around the problem by only doing forward DNS lookups and always working with addresses in the IP domain. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

This is a common problem. Binding to '127.0.0.1' will bind to *only* that address;

Indeed.

binding to "" will bind to *all* addresses the machine is known by.

Agreed again. I believe what we're dealing with here though is a lack of clarity regarding what role the 'address' attribute exposed by multiprocess.connection.Listener should play. The way test_listener_client() is written, it effectively treats 'address' as an end-point that can be connected to directly (irrespective of the underlying family (i.e. AF_INET, AF_UNIX, AF_PIPE)). I believe the problems we've run into stem from the fact that the API doesn't provide any guarantees as to what 'address' represents. The test suite assumes it always reflects a connectable end-point, which I think is more than reasonable. Unfortunately, nothing stops us from breaking this invariant by constructing the object as Listener(family='AF_INET', address=('0.0.0.0', 0)). How do I connect to an AF_INET Listener (i.e. SocketListener) instance whose 'address' attribute reports '0.0.0.0' as the host? I can't. So, for now, I think we should enforce this invariant by raising an exception in Listener.__init__() if self._socket.getsockbyname()[0] returns '0.0.0.0'. In effect, tightening up the API such that we can guarantee Listener.address will always represent a connectable end-point. We can look at how to service 'listen on all available interfaces' semantics at a later date -- that adds far less value IMO than being able to depend on the said guarantee. Thoughts? Trent.

I just found the cause of the problem ten minutes ago: It seems that when a socket listens on the address "127.0.0.1" or "localhost", another process cannot connect to it using the machine's name (even from the same machine). The best seems to listen with the empty address "".

That doesn't seem right. If that were the case, none of the hundreds of network-oriented tests would work either. These all bind against ('localhost', 0) by default which seems to Do The Right Thing on all the platforms we have buildbots for. Trent.