Re: [PATCH] fuse: allow CAP_SYS_ADMIN in root userns to access allow_other mount

[Miklos Szeredi <miklos@szeredi.hu>]

On Wed, 18 May 2022 at 13:22, Christian Brauner <brauner@kernel.org> wrote:
>
> On Tue, May 17, 2022 at 12:50:32PM -0400, Dave Marchevsky wrote:

> > Sorry to ressurect this old thread. My proposed alternate approach of "special
> > ioctl to grant exception to descendant userns check" proved unnecessarily
> > complex: ioctls also go through fuse_allow_current_process check, so a special
> > carve-out would be necessary for in both ioctl and fuse_permission check in
> > order to make it possible for non-descendant-userns user to opt in to exception.
> >
> > How about a version of this patch with CAP_DAC_READ_SEARCH check? This way
> > there's more of a clear opt-in vs CAP_SYS_ADMIN.
>
> I still think this isn't needed given that especially for the use-cases
> listed here you have a workable userspace solution to this problem.
>
> If the CAP_SYS_ADMIN/CAP_DAC_READ_SEARCH check were really just about
> giving a privileged task access then it'd be fine imho. But given that
> this means the privileged task is open to a DoS attack it seems we're
> building a trap into the fuse code.
>
> The setns() model has the advantage that this forces the task to assume
> the correct privileges and also serves as an explicit opt-in. Just my 2
> cents here.

Fully agreed.  Using CAP_DAC_READ_SEARCH instead of CAP_SYS_ADMIN
doesn't make this any better, since root has all caps including
CAP_DAC_READ_SEARCH.

Thanks,
Miklos