From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:57920 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932067AbdBGTCG (ORCPT ); Tue, 7 Feb 2017 14:02:06 -0500 Message-ID: <1486494123.2488.56.camel@HansenPartnership.com> Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount From: James Bottomley To: Christoph Hellwig , Amir Goldstein Cc: Djalal Harouni , Chris Mason , Theodore Tso , Josh Triplett , "Eric W. Biederman" , Andy Lutomirski , Seth Forshee , linux-fsdevel , linux-kernel , LSM List , Dongsu Park , David Herrmann , Miklos Szeredi , Alban Crequy , Al Viro , "Serge E. Hallyn" , Phil Estes Date: Tue, 07 Feb 2017 11:02:03 -0800 In-Reply-To: <20170207181040.GA18551@infradead.org> References: <1486235880.2484.17.camel@HansenPartnership.com> <1486235972.2484.19.camel@HansenPartnership.com> <20170207091924.GA13995@infradead.org> <1486485440.2488.15.camel@HansenPartnership.com> <20170207181040.GA18551@infradead.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 2017-02-07 at 10:10 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 07:59:00PM +0200, Amir Goldstein wrote: > > I am not even sure that would be enough. > > dentry does not contain information about the mount user came from, > > and sb contains only information about the user ns of the mounter > > of > > the file system, not the mounter of the bind mount, right? > > I think I am missing some big pieces of the big picture. > > Would love to hear what Eric has to say. > > IFF we want to do what shiftfs does properly we need vfsmount + > inode, no need for the dentry. Yes, sorry ... I was thinking the dentry contained the mnt, but it doesn't, that's the path. However, threading the mnt through looks substantially harder. > But maybe we need to go back and decice if we want to allow uid/gid > remapping for arbitrary subtrees anyway. So those were the original patches Djalal was referring to. The problem there is that a lot of orchestration systems don't store images they want to bind mount into containers on separately mounted filesystems, which is what's needed to avoid this being per-subtree. However, the clinching argument for me is that the canonical container image *is* a subtree (unlike a vm image which has to be mounted). If we don't make this work on subtrees people go back to daft stacks for containers like copying the image subtree into a loopback mounted filesystem just to make this all work (and then complain about performance and caching and so on). > Another option would be to require something like a project as used > for project quotas as the root. This would also be conveniant as it > could storge the used remapping tables. So this would be like the current project quota except set on a subtree? I could see it being done that way but I don't see what advantage it has over using flags in the subtree itself (the mapping is known based on the mount namespace, so there's really only a single bit of information to store). James