Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <cover.1512741134.git.dongsu@kinvolk.io>
References: <cover.1512741134.git.dongsu@kinvolk.io>
From:   Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue, 13 Feb 2018 12:32:09 +0100
Message-ID: <CAOssrKey+oxahrXHO5d6Lu1ZD=r1t-b0i4iZM_Ke9ToqTckjkQ@mail.gmail.com>
Subject: Re: [PATCH v5 00/11] FUSE mounts from non-init user namespaces
To:     Dongsu Park <dongsu@kinvolk.io>
Cc:     lkml <linux-kernel@vger.kernel.org>,
        containers@lists.linux-foundation.org,
        Alban Crequy <alban@kinvolk.io>,
        "Eric W . Biederman" <ebiederm@xmission.com>,
        Seth Forshee <seth.forshee@canonical.com>,
        Sargun Dhillon <sargun@sargun.me>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park <dongsu@kinvolk.io> wrote:

> Patches 1-2 deal with an additional flag of lookup_bdev() to check for
> additional inode permission.

fuse_blk is less suitable for unprivileged mounting than plain fuse.
fusermount doesn't allow mounting fuse_blk unprivileged, so there's
little data about that usecase (IIRC ntfs3g guys did that, or at least
tried to do it, but I don't remember the details).

As such, I think we should leave it out of the initial version.  Which
means you can drop patches 1-2 from this series.  Unless there's a
strong use case for this.  In which case we should look hard at the
differences between fuse_blk and fuse and how that affects
unprivileged operation.   There are a few assumptions about fuse_blk
filesystem being more "well behaved", I think.

Thanks,
Miklos