From: Sam Vilain (sam_at_vilain.net)
Date: Tue Jul 23 2002 - 12:57:40 EDT
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.
This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:01 EDT