From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Subject: Re: [RFC][PATCH] rbind across namespaces Date: Mon, 30 May 2005 12:06:20 -0700 Message-ID: <1117479979.4359.62.camel@localhost> References: <1116627099.4397.43.camel@localhost> <1116660380.4397.66.camel@localhost> <20050521134615.GB4274@mail.shareable.org> <429277CA.9050300@google.com> <4292D416.5070001@waychison.com> <42935FCB.1010809@google.com> <42936807.2000807@google.com> <42936CA4.1020905@google.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Miklos Szeredi , Jamie Lokier , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , viro@parcelfarce.linux.theplanet.co.uk Return-path: Received: from e35.co.us.ibm.com ([32.97.110.133]:56760 "EHLO e35.co.us.ibm.com") by vger.kernel.org with ESMTP id S261696AbVE3TGw (ORCPT ); Mon, 30 May 2005 15:06:52 -0400 To: Mike Waychison In-Reply-To: <42936CA4.1020905@google.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2005-05-24 at 11:04, Mike Waychison wrote: > Miklos Szeredi wrote: > >>So you'd say 'mount /dev/foo /proc/self/fd/4' if 4 was an fd pointing to > >>a directory in another namespace? > >> > >>That does require proc_check_root be removed. :\ > > > > > > Or just make an exception to self? > > > > proc_check_root() could begin with: > > > > if (current == proc_task(inode)) > > return 0; > > > > For all other tasks it would still be effective. > > > > Yes, I think something like that is workable :) > > (we still have to fix up all the namespace->sem locking. I have yet to > review Ram's patch.) Yes. This patch is not fully ready yet. It still has to take care of using the correct namespace sems for operations like umount/move etc. Have been recently busy with shared subtree coding. Will work on this to remove all the assumptions in the code that think 'a process can access only its own namespace'. RP > > Mike Waychison > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html