From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Poetzl Subject: Re: [RFC] [PATCH 0/4] uid_ns: introduction Date: Thu, 9 Nov 2006 18:17:01 +0100 Message-ID: <20061109171701.GB14687@MAIL.13thfloor.at> References: <20061107041814.GA28706@sergelap.austin.ibm.com> <20061108005209.GA9566@MAIL.13thfloor.at> <1163007970.12491.2.camel@lade.trondhjem.org> <20061108212701.GC8368@MAIL.13thfloor.at> <20061108215449.GA19176@sergelap.austin.ibm.com> <20061109165009.GB16709@sergelap.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Eric W. Biederman" , Containers , linux-fsdevel@vger.kernel.org, Trond Myklebust Return-path: Received: from MAIL.13thfloor.at ([213.145.232.33]:48615 "EHLO MAIL.13thfloor.at") by vger.kernel.org with ESMTP id S1424148AbWKIRRC (ORCPT ); Thu, 9 Nov 2006 12:17:02 -0500 To: "Serge E. Hallyn" Content-Disposition: inline In-Reply-To: <20061109165009.GB16709@sergelap.austin.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Nov 09, 2006 at 10:50:09AM -0600, Serge E. Hallyn wrote: > Quoting Eric W. Biederman (ebiederm@xmission.com): > > "Serge E. Hallyn" writes: > > > > > So from your pov the same objection would apply to tagging vfsmounts, > > > or not? > > > > No. The issue is that the NFS server merges different mounts to the > > same nfs server into the same superblock. > > > > > What is the scenario where the caching is broken? It can't be > > > multiple clients accessing the same NFS export from the same NFS > > > service container, since that would just be an erroneous setup, > > > right? > > > > > > > >> > As I recall there are two basic issues. > > >> > > > >> > Putting the default on the mount structure instead of the > > >> > superblock for filesystems that are not uid namespaces aware > > >> > sounded reasonable, and allowed certain classes of sharing > > >> > between namespaces where they agreed on a subset of the uids > > >> > (especially for read-only data). > > >> > > >> yes, that is especially interesting for --bind mounts > > >> when you 'know' that you will dedicate a certain > > >> sub-tree to one context/guest > > > > > > Ok, so you wouldn't object to a patch which tagged vfsmounts? > > > > > > I guess a NULL vfsmnt->user_ns pointer would mean ignore user_ns and > > > only apply uid checks (useful for ro bind mount of /usr into multiple > > > containers). > > > > Bind mounts are peculiar. But I think as long as you charged > > the to the context in which they happen (don't do the bind > > until after you switch the user_ns. You should be fine. > > Presumably container setup would be somewhat like system boot - you'd > start with a shared / filesystem, unshare user namespace, construct your > new /, pivot_root, and unmount /old_root, so you end up with all > vfsmounts accessible from the container having the correct user_ns. well, once again that is a very narrow view to the real picture, what about the following cases: - folks who _share_ certain filesystems between different guests (maybe for cooperation or just readonly to save resource) - folks who still want a way to access and or andminsitrate the guests (without going through ssh or whatever, e.g. for bulk updates) - prestructured setups (like build roots) which require pre configured mounts to work ... best, Herbert > -serge > _______________________________________________ > Containers mailing list > Containers@lists.osdl.org > https://lists.osdl.org/mailman/listinfo/containers