About this list Date view Thread view Subject view Author view Attachment view

From: Sam Vilain (sam_at_vilain.net)
Date: Tue 23 Jul 2002 - 17:57:40 BST


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?

--
   Sam Vilain, sam_at_vilain.net     WWW: http://sam.vilain.net/
    7D74 2A09 B2D3 C30F F78E      GPG: http://sam.vilain.net/sam.asc
    278A A425 30A9 05B5 2F13
-
A complex system that works is invariably found to have evolved from a
simple system that worked.
 - anon.



About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 06 Nov 2002 - 07:03:41 GMT by hypermail 2.1.3