From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Sat 10 Aug 2002 - 03:59:53 BST
On Tue, 23 Jul 2002 17:57:40 -0500, Sam Vilain wrote
> Hi all,
>
> I have been investigating the new patch, ctx-12. Multiple IP addresses
> opens up the possibility that I think could fix the `localhost' business
> for good: per-vserver loopback interfaces.
>
> In the vserver startup script, the address 127.0.0.N, where N is some arbitrary number
> allocated in userland, is added to the list of allowable addresses in the set_ipv4root
> call, and the interface up'ed (not sure if this is strictly needed; try running `netcat
> -s 127.1.2.3 -p 1234 -l' and then `telnet 127.1.2.3 1234' - it works anyway).
>
> There are two ways to get a `localhost' address from an application - one
> is to try and resolve `localhost', which is fine - but any program with a
> severe case of C programmer's disease will be doing it using the
> getaddrinfo() function - see the attached file.
>
> This C library call seems to escape /etc/resolv.conf, /etc/nsswitch.conf,
> /etc/hosts and INADDR_LOOPBACK is #define'd as a constant by glibc in
> /usr/include/netinet/in.h. This is not necessarily a huge problem, as
> getaddrinfo() can be redefined via LD_PRELOAD or ld.so.conf, or fixed in
> the C library.
>
> I think per-vserver localhosts would have several advantages:
> - You get a localhost interface to yourself, for setting up
> applications that do not support UNIX sockets to listen on, port
> forwarding, etc.
> - Applications that listen on localhost don't potentially expose
> services to the world
> - More like a real server :-) In other words, some applications may
> consider binding to an address and having getsockopt() or whatever it
> is returning the same address a sanity condition.
> - Make use of that 127.* class A network that has sat so unused for all
> these years.
>
> The only problem will be if any userland applications out there use the incorrect
> (according to RFC1062) INADDR_LOOPBACK macro.
>
> The other possibility would be to find all of the places in the kernel
> that could accept 127.0.0.1 and translate it to a per-virtual server
> localhost interface transparently. So userland thinks it's got 127.0.0.1,
> but the networking stack uses 127.0.0.X. I guess this would save having
> to make sweeping userland changes, although I think fixing the C library would be
> The Right Thing(tm) in the long run.
>
> Ideas/comments?
There is a major issue with per-vserver loopback. Most application assumes
that binding to 0.0.0.0 grabs everything, including the loopback. The private
loopback here would mean the application has to bind to localhost as well.
Currently, we remap connection to localhost to the ipv4root and this satisfies most
client.
So if we implement a private loopback, we must also implement the mapping
between 0.0.0.0 (ANYADDR) to ipv4root and loopback.
Something like this was done to support UDP broadcast. A very minor change
was done to struct socket (You all remember the buggy ctx-9) so a socket
is bound to two IP address. Thos could be reused to address that.
So instead of having 0.0.0.0 remap to handle any IP of the vserver, this
could be remap to handle the first IP of the ipv4root set and the private loopback.
This is probably very easy to do.
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc