Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

From: James Bottomley
Date: Wed Feb 22 2017 - 07:02:02 EST

On Mon, 2017-02-20 at 17:24 +1300, Eric W. Biederman wrote:
> James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes:
> > On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote:
> > > I think I am missing something but I completely do not understand
> > > that subthread that says use file marks and perform the work in
> > > the vfs. The problem is that fundamentally we need multiple
> > > mappings and I don't see a mark on a file (even an inherited
> > > mark) providing the mapping so I don't see the point.
> >
> > The point of the mark is that it's a statement by the system
> > administrator that the underlying subtree is safe to be mounted by
> > an unprivileged container in the containers user view (i.e. with
> > current_user_ns() == s_user_ns). For the unprivileged container
> > there's no real arbitrary s_user_ns use case because the
> > unprivileged container must prove it can set up the mapping, so it
> > would likely always be mounting from within a user_ns with the
> > mapping it wanted.
> As a statement that it is ok for the unprivileged mapping code to
> operate that seems reasonable. I don't currently the need for such
> an ok from the system adminstrator, but if you need it a flag that
> propagates to children and child directories seems reasonable.

The other way to do this is with an extended attribute. I've played
around with that approach and quite like it: the advantage is that it's
sticky across system reboots; The down side is that it requires
additional VFS code to make sure you can't execute from the non-user_ns