[redhat-lspp] Re: LSPP Development Telecon 06/19/2006 Minutes

[Eric W. Biederman]

Dave Hansen <haveblue at us.ibm.com> writes:

> Quoting Ted (txtoth at gmail.com):
>> Can anyone point me to a good source of information on namespaces in
>> general and network namespaces specifically. Are network namespaces
>> something that could be utilized through xinetd to get polyinstantiated
>> port functionality?
>
> I was just talking to Serge about this on IRC a bit.  I think network
> namespaces might do some of what you want.
>
> Note that this is coming from somebody (me) that has never written a
> line of networking code in his life.  So, don't pay too much attention.
> Just brainstorming.
>
> One of the important things that they give you is the ability to have
> multiple stupid daemons listening on "*:80".  Each daemon thinks they
> "own" that port.  However, the network namespace patches make sure that
> such a daemon doesn't receive any packets not meant for an IP owned by
> that daemon.
>
> So, if you added network namespaces with a rewriting netfilter rule that
> would mangle destination addresses to match the IP address of a
> containerized daemon, I _think_ you might be able to get what you want.
>
> So,
>
> 1. packet comes in for port 80
> 2. packet is tagged by secmark
> 3. packet matches netfilter rule, is redirected to a _specific_ IP
> 4. packet reaches containerized daemon listening on port 80

Ack.  That would probably work.

I'm not certain what is meant by a polyinstantiated port,
and until then I can't see if it helps.

Network connections are a quad of
<source address, source port, destination address, destination port>
which cover all of the interesting cases I can think of for connecting
things together.  I don't know what else you can filter on.

The way to think about network namespaces from a user perspective are
simply multiple instances of the networking stack.  If you can do something
today with linux and multiple machines you will eventually be able to do
it on one machine with network namespaces.

Assuming we can reach an implementation without measurable overhead.

Eric