Re: [PATCH v3 00/11] fuse: basic support for idmapped mounts

[Christian Brauner]

On Thu, Aug 15, 2024 at 11:24:17AM GMT, Alexander Mikhalitsyn wrote:
> Dear friends,
> 
> This patch series aimed to provide support for idmapped mounts
> for fuse & virtiofs. We already have idmapped mounts support for almost all
> widely-used filesystems:
> * local (ext4, btrfs, xfs, fat, vfat, ntfs3, squashfs, f2fs, erofs, ZFS (out-of-tree))
> * network (ceph)
> 
> Git tree (based on torvalds/master):
> v3: https://github.com/mihalicyn/linux/commits/fuse_idmapped_mounts.v3
> current: https://github.com/mihalicyn/linux/commits/fuse_idmapped_mounts
> 
> Changelog for version 3:
> - introduce and use a new SB_I_NOIDMAP flag (suggested by Christian)
> - add support for virtiofs (+user space virtiofsd conversion)
> 
> Changelog for version 2:
> - removed "fs/namespace: introduce fs_type->allow_idmap hook" and simplified logic
> to return -EIO if a fuse daemon does not support idmapped mounts (suggested
> by Christian Brauner)
> - passed an "idmap" in more cases even when it's not necessary to simplify things (suggested
> by Christian Brauner)
> - take ->rename() RENAME_WHITEOUT into account and forbid it for idmapped mount case
> 
> Links to previous versions:
> v2: https://lore.kernel.org/linux-fsdevel/20240814114034.113953-1-aleksandr.mikhalitsyn@xxxxxxxxxxxxx
> tree: https://github.com/mihalicyn/linux/commits/fuse_idmapped_mounts.v2
> v1: https://lore.kernel.org/all/20240108120824.122178-1-aleksandr.mikhalitsyn@xxxxxxxxxxxxx/#r
> tree: https://github.com/mihalicyn/linux/commits/fuse_idmapped_mounts.v1
> 
> Having fuse (+virtiofs) supported looks like a good next step. At the same time
> fuse conceptually close to the network filesystems and supporting it is
> a quite challenging task.
> 
> Let me briefly explain what was done in this series and which obstacles we have.
> 
> With this series, you can use idmapped mounts with fuse if the following
> conditions are met:
> 1. The filesystem daemon declares idmap support (new FUSE_INIT response feature
> flags FUSE_OWNER_UID_GID_EXT and FUSE_ALLOW_IDMAP)
> 2. The filesystem superblock was mounted with the "default_permissions" parameter
> 3. The filesystem fuse daemon does not perform any UID/GID-based checks internally
> and fully trusts the kernel to do that (yes, it's almost the same as 2.)
> 
> I have prepared a bunch of real-world examples of the user space modifications
> that can be done to use this extension:
> - libfuse support
> https://github.com/mihalicyn/libfuse/commits/idmap_support
> - fuse-overlayfs support:
> https://github.com/mihalicyn/fuse-overlayfs/commits/idmap_support
> - cephfs-fuse conversion example
> https://github.com/mihalicyn/ceph/commits/fuse_idmap
> - glusterfs conversion example (there is a conceptual issue)
> https://github.com/mihalicyn/glusterfs/commits/fuse_idmap
> - virtiofsd conversion example
> https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/245

So I have no further comments on this and from my perspective this is:

Reviewed-by: Christian Brauner <brauner@xxxxxxxxxx>

I would really like to see tests for this feature as this is available
to unprivileged users.