Hello Eric, in 2018 you commited to the FS subsystem a patch to enable mounting FUSE filesystems inside user namespaces, for which I am grateful. That patch (https://lore.kernel.org/all/87tvqqo8w1.fsf_-_@xxxxxxxxxxxx/) enabled the FS_USERNS_MOUNT filesystem flag for the "fuse" filesystem type. To the best of my understanding, this allows any program owning the CAP_SYS_ADMIN privilege inside its user namespace to mount filesystems of that type (unlike the default behavior for filesystems, ~FS_USERNS_MOUNT, that requires owning CAP_SYS_ADMIN inside the "initial" user namespace): https://elixir.bootlin.com/linux/latest/source/fs/super.c#L516. However that option was not enabled on the "fuseblk" filesystem type. I discovered this today while trying to use ntfs-3g on a block device inside an unprivileged container. Looking at it a bit further with a colleague, we realized that programs like fusefat worked because they relied on the "fuse" type, and not "fuselblk". Which is finally what led me to believe that the lack of the FS_USERNS_MOUNT flag was the culprit. And indeed, patching ntfs-3g to always use the "fuse" filesystem type instead of the preferred "fuseblk" works reliably, so at least we know some way to bypass that issue. However, we were curious to know if I missed some rationale that would prevent that flag for being usable on "fuseblk" too? And if they weren't, would you be opposed to a patch similar to what follows? diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index 6b3beda16c1b..d17f87531dc8 100644 --- a/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -1839,7 +1839,7 @@ static struct file_system_type fuseblk_fs_type = { .init_fs_context = fuse_init_fs_context, .parameters = fuse_fs_parameters, .kill_sb = fuse_kill_sb_blk, - .fs_flags = FS_REQUIRES_DEV | FS_HAS_SUBTYPE, + .fs_flags = FS_REQUIRES_DEV | FS_HAS_SUBTYPE | FS_USERNS_MOUNT, }; MODULE_ALIAS_FS("fuseblk"); Sorry to bother you with this 4 years after the patch ^^ Thanks, Simon
