Gabriel Genellina wrote:
James Mills escribió:
Bryan Olson wrote:
I thought a firewall would block an attempt to bind to any routeable
address, but not to localhost. So using INADDR_ANY would be rejected.
No.
My understanding is that firewalls block network traffic, not system
calls.
This is correct. Firewalls (real firewalls) can only act on incoming
and outgoing traffic on the IP level.
That's true for hardware firewalls (those found in a router, by
example). They can at most analyze traffic at the application layer but
have no idea of the applications (processes) behind.
A "software firewall" may react not just to traffic but to *who* is
doing that; it may block *processes* when they try to bind/listen to any
port, even before any packet is sent or received. See
http://www.securityfocus.com/infocus/1839
(One may argue whether those are *real* firewalls or not, but that's
their common name...)
Even if one's 'firewall' product is one of "the rather useless ones that
merely hook socket calls" (in the words of the linked article), I still
don't see failing a bind() to INADDR_ANY while allowing a bind() to
127.0.0.1. INADDR_ANY means all available adapters. If some physical
network adapter should be unavailable while the loopback is allowed,
fine; passing INADDR_ANY should work and bind to the loopback adapter.
(Also note that I'm far for being an expert on these topics)
Sure. I was mostly just making a couple points because at one time they
confused me. Python's socket.bind() treats the empty string as
INADDR_ANY, which means all available adapters. It's a fine address
parameter for bind(), and ought to work at least as well as any. The
time to bind() to localhost is when we specifically do not want to be
available on an external network adapter.
Now don't get me started on the vagaries of passing INADDR_ANY to connect().
--
--Bryan
--
http://mail.python.org/mailman/listinfo/python-list
