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 10:40:49 +0200 Message-ID: <47035591.4030300@fr.ibm.com> References: <4702BBF4.60903@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: > >> Hi, >> >> I was looking at some cornercases and trying to figure out what happens if >> someone does: >> >> 1 - fd = socket(...) >> 2 - unshare(CLONE_NEWNET) >> 3 - bind(fd, ...) / listen(fd, ...) >> >> There is here an interaction between two namespaces. >> Trying to catch all these little tricky paths everywhere with the network >> namespace is painful, perhaps we should consider a more radical solution. > > Huh? > > socket() puts the namespace on struct sock. > bind/listen etc just look at that namespace. > > Unless I'm blind it is simple and it works now. 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. >> 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 ?