From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bedivere.hansenpartnership.com ([66.63.167.143]:42910 "EHLO
        bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1754689AbdBVMBh (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 22 Feb 2017 07:01:37 -0500
Message-ID: <1487764890.2376.2.camel@HansenPartnership.com>
Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>,
        Amir Goldstein <amir73il@gmail.com>,
        Djalal Harouni <tixxdz@gmail.com>, Chris Mason <clm@fb.com>,
        Theodore Tso <tytso@mit.edu>,
        Josh Triplett <josh@joshtriplett.org>,
        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>
Date: Wed, 22 Feb 2017 07:01:30 -0500
In-Reply-To: <87ino5ebfv.fsf@xmission.com>
References: <1486235880.2484.17.camel@HansenPartnership.com>
         <1486235972.2484.19.camel@HansenPartnership.com>
         <CAOQ4uxjRYZCA8mHw_YNTfDDZoOMO9qD-nJyw2qWAypNxmYNALQ@mail.gmail.com>
         <1486343891.2496.54.camel@HansenPartnership.com>
         <20170214230305.GC4017@redhat.com>
         <1487115955.3133.73.camel@HansenPartnership.com>
         <20170215141734.GA2101@redhat.com>
         <1487260318.2944.18.camel@HansenPartnership.com>
         <20170216164233.GC23490@redhat.com>
         <1487264301.2944.51.camel@HansenPartnership.com>
         <87a89l7f4y.fsf@xmission.com>
         <1487351993.4351.17.camel@HansenPartnership.com>
         <87ino5ebfv.fsf@xmission.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Mon, 2017-02-20 at 17:24 +1300, Eric W. Biederman wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> 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
view.

James