[Devel] Re: netns : close all sockets at unshare ?

Eric W. Biederman ebiederm at xmission.com
Wed Oct 3 09:59:07 PDT 2007


Daniel Lezcano <dlezcano at fr.ibm.com> writes:
>
> Yes, it will work.
>
> Do we want to be inside a network namespace and to use a socket belonging to
> another network namespace ? If yes, then my remark is irrelevant.

Yes we do.

>>> Shall we close all fd sockets when doing an unshare ? like a close-on-exec
>>> behavior ?
>>
>> I think adopting that policy would dramatically reduce the usefulness
>> of network namespaces.
>>
>> Making the mix and match cases gives the implementation much more flexibility
>> and it doesn't appear that hard right now.
>
> I am curious, why such functionality is useful ?

There are several reasons.  Partly it is the principle of building
general purpose tools that can be used in a flexible way.

The biggest practical use I can see is that a control program outside
of a network namespace can configure and setup someone else's network
stack, perhaps preventing the need to enter someone else's container.

Another use is having a socket in an original network namespace for
doing a stdin/stdout style connections.

The planetlab folks are actually actively using this functionality
already, and there was a thread several months ago about how this
functionality was important and how they were using it.

This also preserves normal unix file descriptor passing semantics.

A final reason for it is that it removes the need for a lot of
brittle special cases when network namespaces are mixed in something
other then a 1-1 correspondence with other namespaces.  Like the one
you were concerned with in unshare.  Handling this case means
everything just works.

So it may be a touch harder to implement but because we don't add
special rules it is much easier to review.

Eric
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list