getaddrinfo(NULL, x, {ai_flags=>AI_PASSIVE}, x) answer hardcoded

[Sam Vilain <sam at vilain dot net>]

>From getaddrinfo(3):

       If node is NULL, the network address in each socket struc­
       ture  is  initialized  according  to  the AI_PASSIVE flag,
       which is set in the ai_flags member of the  hints  parame­
       ter.  The network address in each socket structure will be
       left unspecified if AI_PASSIVE flag is set.  This is  used
       by server applications, which intend to accept client con­
       nections on any network address.  The network address will
       be set to the loopback interface address if the AI_PASSIVE
       flag is not set.  This is  used  by  client  applications,
       which  intend  to  connect to a server running on the same
       network host.

It seems that the getaddrinfo() function implements this by simply
returning 127.0.0.1, as defined in inet/netinet/in.h in the source
distribution; however it is my current belief that the correct
behaviour should be to attempt to resolve `localhost' and return the
answer as a last ditch option; to assume it is always going to be the
first address on the network is somewhat limiting.

Now, I want all you people who get enjoyment out of telling people
categorically that something is not possible without verifying and
backing up your comments to help yourself to a piping hot cup of shut
the fuck up.  I want to talk solutions here and the last thing anyone
needs is a flamewar.  Think before you post.

What do the standards say?

>From RFC 1062:

 The class A network number 127 is assigned the "loopback" function,
    that is, a datagram sent by a higher level protocol to a network 127
   address should loop back inside the host.  No datagram "sent" to a
   network 127 address should ever appear on any network anywhere.

There is no mention of 127.0.0.1 being ``the'' loopback address.  I
couldn't find it anywhere, and I searched long and hard.  Maybe
someone else out there can settle this by pointing out where it
mentions it.

You may be asking myself, why do I care?

For the Linux vserver project
(http://www.solucorp.qc.ca/miscprj/s_context.hc), attaching to
localhost fails because we disallow bind() calls to 127.0.0.1,
transparently mapping them to a bind call to the first in a
per-vserver list of IP addresses open in the kernel.

Otherwise, a system inside one vserver might try to bind to 127.0.0.1,
and reasonably expect that no other systems be able to access that
directly, but all would be able to access it.

The problem is that applications like SSH correctly call getaddrinfo()
when they want to bind to a local address (for SSH port forwarding,
etc).

This is the best plan I have come up with.

  A) Deprecate the use of the INADDR_LOOPBACK macro

  B) Add the functionality to get a controllable answer back from
     getaddrinfo() - either with a new socket IOCTL and some kernel
     side help, or by resolving `localhost'.  This might not always be
     possible, if we are already inside a resolve request which wants
     to use RPC or something like that, I expect this will fail.

The vserver system is an incredibly lightweight way to achieve virtual
Unix servers.  Its overhead is virtually nothing, and with some hard
link trickery it is even possible to avoid having multiple copies of
executable images between vservers in memory.

Anyone have any suggestions of an approach or other relevant ideas?

Cheers,
--
   Sam Vilain, sam@vilain.net     WWW: http://sam.vilain.net/
    7D74 2A09 B2D3 C30F F78E      GPG: http://sam.vilain.net/sam.asc
    278A A425 30A9 05B5 2F13

  America is the only country that went from barbarism to decadence
without civilization in between.
OSCAR WILDE