On Wed, 18 May 2022 at 13:22, Christian Brauner <brauner@xxxxxxxxxx> 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
