From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lezcano Subject: Re: netns : close all sockets at unshare ? Date: Wed, 03 Oct 2007 21:33:42 +0200 Message-ID: <4703EE96.6060708@fr.ibm.com> References: <4702BBF4.60903@fr.ibm.com> <47035591.4030300@fr.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: Linux Containers List-Id: containers.vger.kernel.org Eric W. Biederman wrote: > Daniel Lezcano 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. Very interesting. Thank you for taking the time to answer. -- Daniel