linux-kernel - Re: [PATCH v5 00/11] FUSE mounts from non-init user namespaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Feb 2018 12:32:09 +0100
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Dongsu Park <dongsu@...volk.io>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        containers@...ts.linux-foundation.org,
        Alban Crequy <alban@...volk.io>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Seth Forshee <seth.forshee@...onical.com>,
        Sargun Dhillon <sargun@...gun.me>
Subject: Re: [PATCH v5 00/11] FUSE mounts from non-init user namespaces

On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park <dongsu@...volk.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