From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932196AbdBHGwm (ORCPT ); Wed, 8 Feb 2017 01:52:42 -0500 Received: from mail-ot0-f194.google.com ([74.125.82.194]:35681 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752924AbdBHGwj (ORCPT ); Wed, 8 Feb 2017 01:52:39 -0500 MIME-Version: 1.0 In-Reply-To: <1486510955.2488.74.camel@HansenPartnership.com> 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> <1486494123.2488.56.camel@HansenPartnership.com> <20170207194933.GB4393@infradead.org> <1486497908.2488.64.camel@HansenPartnership.com> <20170207222551.GA17206@infradead.org> <1486510955.2488.74.camel@HansenPartnership.com> From: Amir Goldstein Date: Wed, 8 Feb 2017 08:44:18 +0200 Message-ID: Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount To: James Bottomley Cc: Christoph Hellwig , 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 , Konstantin Khlebnikov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley wrote: > On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: >> On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: >> > Project id's are not exactly "subtree" semantic, but inheritance >> > semantics, >> > which is not the same when non empty directories get their project >> > id changed. >> > Here is a recap: >> > https://lwn.net/Articles/623835/ >> >> Yes - but if we abuse them for containers we could refine the >> semantics to simply not allow change of project ids from inside >> containers based on say capabilities. > You mean something like this: https://lwn.net/Articles/632917/ With the suggested protected_projects, projid 0 (also inside container) gets a special meaning, much like user 0, so we may do interesting things with the projid that is mapped to 0. > We can't really abuse projectid, it's part of the user namespace > mapping (for project quota). What we can do is have a new id that > behaves like it. > Perhaps we *can* use projid without abusing it. userns already maps projids, but there is no concept of "owning project" for a userns, nor does it make a lot of sense, because projid is not part of the credentials. But if we re-brand it as "container root projid", we can try to use it for defining semantics to grant unprivileged access to a subtree. The functionality you are trying to get with shiftfs mark does sounds a bit like "container root projid": - inodes with mapped projid MAY be uid/gid shifted - inodes with unmapped projid MAY NOT I realize this may be very raw, but its a start. If you like this direction we can try to develop it. > But like I said, we don't really need a ful ID, it would basically just > be a single bit mark to say remap or not when doing permission checks > against this inode. It would follow some of the project id semantics > (like inheritance from parent dir) > But a single bit would only work for single level of userns nesting won't it? >> > I guess we should define the semantics for the required sub-tree >> > marking, before we can talk about solutions. >> >> Good plan. > > So I've been thinking about how to do this without subtree marking and > yet retain the subtree properties similar to project id. The advantage > would be that if it can be done using only inode properties, then none > of the permission prototypes need change. The only real subtree > property we need is ability to bind into an unprivileged mount > namespace, but we already have that. The gotcha about marking inodes > is that they're all or nothing, so every subtree that gets access to > the inode inherits the mark. This means that we cannot allow a user > access to a marked inode without the cover of an unprivileged user > namespace, but I think that's fixable in the permission check > (basically if the inode is marked you *only* get access if you have a > user_ns != init_user_ns and we do the permission shifts or you have > user_ns == init_user_ns and you are admin capable). > I didn't follow, but it sounds like your proposed solutions is only good for single level of userns nesting. Do you think you can redefine it in terms of "container root projid".