From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [PATCH 2/18] cleanups and bug fix in do_loopback() Date: Wed, 09 Nov 2005 16:51:08 -0800 Message-ID: <1131583868.5400.685.camel@localhost> References: <1131439567.5400.221.camel@localhost> <1131563299.5400.392.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Al Viro , torvalds@osdl.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: To: Miklos Szeredi In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-11-09 at 13:15, Miklos Szeredi wrote: > > Yes there is some contradiction of some sorts on this. private-ness > > means that the namespace must _not_ be accesible to processes > > in other namespace. But 'file descriptor sent between two processes in > > different namespaces' seems to break that guarantee. > > So..., are we going to check namespace in every file operation? How > much do you want to bet, that it won't break any applications? I don't know. May be there are applications out there that depend on this. It depends on the definition of private-ness of namespace. I am just saying that you raise a valid point. I am not sure if fixing this behavior hurts more or soothes more, Any idea? RP > > > > Also with ptrace() you can still access other process's namespace, so > > > proc_check_root() is also too strict (or ptrace() too lax). > > > > same here. > > You mean, that ptrace() _is_ too lax? Adding a namespace check to > ptrace might well cause grief too. > > The real question is, how private do we want the namespace to be. I > don't believe, we need to make it any more private than it currently > is. > > Miklos