From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Christoph Hellwig <hch@infradead.org>,
Amir Goldstein <amir73il@gmail.com>
Cc: Djalal Harouni <tixxdz@gmail.com>, Chris Mason <clm@fb.com>,
Theodore Tso <tytso@mit.edu>,
Josh Triplett <josh@joshtriplett.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andy Lutomirski <luto@kernel.org>,
Seth Forshee <seth.forshee@canonical.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
Dongsu Park <dongsu@endocode.com>,
David Herrmann <dh.herrmann@googlemail.com>,
Miklos Szeredi <mszeredi@redhat.com>,
Alban Crequy <alban.crequy@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
"Serge E. Hallyn" <serge@hallyn.com>,
Phil Estes <estesp@gmail.com>
Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
Date: Tue, 07 Feb 2017 15:42:35 -0800 [thread overview]
Message-ID: <1486510955.2488.74.camel@HansenPartnership.com> (raw)
In-Reply-To: <20170207222551.GA17206@infradead.org>
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.
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.
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)
> > 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).
James
next prev parent reply other threads:[~2017-02-07 23:42 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-04 19:18 [RFC 0/1] shiftfs: uid/gid shifting filesystem (s_user_ns version) James Bottomley
2017-02-04 19:19 ` [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley
2017-02-05 7:51 ` Amir Goldstein
2017-02-06 1:18 ` James Bottomley
2017-02-06 6:59 ` Amir Goldstein
2017-02-06 14:41 ` James Bottomley
2017-02-14 23:03 ` Vivek Goyal
2017-02-14 23:45 ` James Bottomley
2017-02-15 14:17 ` Vivek Goyal
2017-02-16 15:51 ` James Bottomley
2017-02-16 16:42 ` Vivek Goyal
2017-02-16 16:58 ` James Bottomley
2017-02-17 1:57 ` Eric W. Biederman
2017-02-17 8:39 ` Djalal Harouni
2017-02-17 17:19 ` James Bottomley
2017-02-20 4:24 ` Eric W. Biederman
2017-02-22 12:01 ` James Bottomley
2017-02-06 3:25 ` J. R. Okajima
2017-02-06 6:38 ` Amir Goldstein
2017-02-06 16:29 ` James Bottomley
2017-02-06 6:46 ` James Bottomley
2017-02-06 14:50 ` Theodore Ts'o
2017-02-06 15:18 ` James Bottomley
2017-02-06 15:38 ` lkml
2017-02-06 17:32 ` James Bottomley
2017-02-06 21:52 ` J. Bruce Fields
2017-02-07 0:10 ` James Bottomley
2017-02-07 1:35 ` J. Bruce Fields
2017-02-07 19:01 ` James Bottomley
2017-02-07 19:47 ` Christoph Hellwig
2017-02-06 16:24 ` J. R. Okajima
2017-02-21 0:48 ` James Bottomley
2017-02-21 2:57 ` J. R. Okajima
2017-02-21 4:07 ` James Bottomley
2017-02-21 4:34 ` J. R. Okajima
2017-02-07 9:19 ` Christoph Hellwig
2017-02-07 9:39 ` Djalal Harouni
2017-02-07 9:53 ` Christoph Hellwig
2017-02-07 16:37 ` James Bottomley
2017-02-07 17:59 ` Amir Goldstein
2017-02-07 18:10 ` Christoph Hellwig
2017-02-07 19:02 ` James Bottomley
2017-02-07 19:49 ` Christoph Hellwig
2017-02-07 20:05 ` James Bottomley
2017-02-07 21:01 ` Amir Goldstein
2017-02-07 22:25 ` Christoph Hellwig
2017-02-07 23:42 ` James Bottomley [this message]
2017-02-08 6:44 ` Amir Goldstein
2017-02-08 11:45 ` Konstantin Khlebnikov
2017-02-08 14:57 ` James Bottomley
2017-02-08 15:15 ` James Bottomley
2017-02-08 1:54 ` Josh Triplett
2017-02-08 15:22 ` James Bottomley
2017-02-09 10:36 ` Josh Triplett
2017-02-09 15:34 ` James Bottomley
2017-02-13 10:15 ` Eric W. Biederman
2017-02-15 9:33 ` Djalal Harouni
2017-02-15 9:37 ` Eric W. Biederman
2017-02-15 10:04 ` Djalal Harouni
2017-02-07 18:20 ` James Bottomley
2017-02-07 19:48 ` Djalal Harouni
2017-02-15 20:34 ` Vivek Goyal
2017-02-16 15:56 ` James Bottomley
2017-02-17 2:55 ` Al Viro
2017-02-17 17:34 ` James Bottomley
2017-02-17 20:35 ` Vivek Goyal
2017-02-19 3:24 ` James Bottomley
2017-02-20 19:26 ` Vivek Goyal
2017-02-21 0:38 ` James Bottomley
2017-02-17 2:29 ` Al Viro
2017-02-17 17:24 ` James Bottomley
2017-02-17 17:51 ` Al Viro
2017-02-17 20:27 ` Vivek Goyal
2017-02-17 20:50 ` James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2016-05-12 19:06 [RFC 0/1] shiftfs: uid/gid shifting filesystem James Bottomley
2016-05-12 19:07 ` [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley
2016-05-16 19:41 ` Serge Hallyn
2016-05-17 2:28 ` James Bottomley
2016-05-17 3:47 ` Serge E. Hallyn
2016-05-17 10:23 ` James Bottomley
2016-05-17 20:59 ` James Bottomley
2016-05-19 2:28 ` Serge E. Hallyn
2016-05-19 10:53 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1486510955.2488.74.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=alban.crequy@gmail.com \
--cc=amir73il@gmail.com \
--cc=clm@fb.com \
--cc=dh.herrmann@googlemail.com \
--cc=dongsu@endocode.com \
--cc=ebiederm@xmission.com \
--cc=estesp@gmail.com \
--cc=hch@infradead.org \
--cc=josh@joshtriplett.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mszeredi@redhat.com \
--cc=serge@hallyn.com \
--cc=seth.forshee@canonical.com \
--cc=tixxdz@gmail.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).