From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Subject: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call Date: Wed, 20 Apr 2005 11:33:16 -0700 Message-ID: <1114021996.4920.168.camel@localhost> References: <20050419222324.GM13052@parcelfarce.linux.theplanet.co.uk> <20050420033304.GO13052@parcelfarce.linux.theplanet.co.uk> <20050420094558.GB10167@mail.shareable.org> <20050420102711.GR13052@parcelfarce.linux.theplanet.co.uk> <20050420120340.GC10167@mail.shareable.org> <20050420123945.GS13052@parcelfarce.linux.theplanet.co.uk> <1114015886.4920.120.camel@localhost> <20050420170921.GT13052@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , Eric Van Hensbergen , linux-fsdevel@vger.kernel.org Return-path: Received: from e34.co.us.ibm.com ([32.97.110.132]:14991 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S261792AbVDTSdl (ORCPT ); Wed, 20 Apr 2005 14:33:41 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3KIXfeE386470 for ; Wed, 20 Apr 2005 14:33:41 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3KIXdaC258862 for ; Wed, 20 Apr 2005 12:33:39 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3KIXcgb023009 for ; Wed, 20 Apr 2005 12:33:39 -0600 To: Al Viro In-Reply-To: <20050420170921.GT13052@parcelfarce.linux.theplanet.co.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-04-20 at 10:09, Al Viro wrote: > On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote: > > Reading through the thread I assume the requirement is: > > > > 1) A User being able to create his own VFS-mount environment > > 2) being able to use the same VFS-mount environment from > > multiple login sessions. > > 3) Being able to switch some processes to some other > > VFS-mount environment. > > Excuse me, but could somebody give coherent rationale for such requirements? > _Especially_ for joining existing group by completely unrelated process - > something we don't do for any other component of process. Would it be wrong to do (3) if access-controlled properly? Currently the only way to share the same namespace is to inherit it, which is possible only if the process belongs to the heridity chain of the creator of the namespace. I extracted the requirement (3) from this discussion -------------------------------------------------------------------- > We think namespaces are a nice way to do that: making a user-owned > filesystem only visible to a user. But the mechanism of CLONE_NEWNS > does not work, because it presumes namespace divisions are only > propagated over parent-child divisions, like environment variables. > What we really want is a mount point that propagates across all the > processes owned by one user, but is not there for other users. This is almost certainly bogus. Same user can easily want several different environments set on the same box. -------------------------------------------------------------------- RP > - > 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