On Tue, Mar 5, 2024 at 3:38 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Mon, 8 Jan 2024 at 13:10, Alexander Mikhalitsyn > <aleksandr.mikhalitsyn@xxxxxxxxxxxxx> wrote: > > > > To properly support vfs idmappings we need to provide > > a fuse daemon with the correct owner uid/gid for > > inode creation requests like mkdir, mknod, atomic_open, > > symlink. > > > > Right now, fuse daemons use req->in.h.uid/req->in.h.gid > > to set inode owner. These fields contain fsuid/fsgid of the > > syscall's caller. And that's perfectly fine, because inode > > owner have to be set to these values. But, for idmapped mounts > > it's not the case and caller fsuid/fsgid != inode owner, because > > idmapped mounts do nothing with the caller fsuid/fsgid, but > > affect inode owner uid/gid. It means that we can't apply vfsid > > mapping to caller fsuid/fsgid, but instead we have to introduce > > a new fields to store inode owner uid/gid which will be appropriately > > transformed. Hi Miklos, > > Does fsuid/fsgid have any meaning to the server? As far as I know, some servers use fsuid/fsgid values in server-side permission checks. Sometimes, for example in Glusterfs, even when "default_permissions" fuse mount option is enabled these values are still used for permission checks. And yes, this is a problem for idmapped mount support. That's why we need to have some fuse connection flag from the server side which means "yes, I'm aware of idmapped mounts and I really want it" (FUSE_ALLOW_IDMAP). > > Shouldn't this just set in.h.uid/in.h.gid to the mapped ids? > It is a very good and tricky question ;-) We had big debates like a year ago when Christian and I were working on idmapped mounts support for cephfs [1]. This was a first Christian's idea when he originally proposed a patchset for cephfs [2]. The problem with this approach is that we don't have an idmapping provided in all inode_operations, we only have it where it is supposed to be. To workaround that, Christian suggested applying a mapping only when we have mnt_idmap, but if not just leave uid/gid as it is. This, of course, leads to inconsistencies between different inode_operations, for example ->lookup (idmapping is not applied) and ->symlink (idmapping is applied). This inconsistency, really, is not a big deal usually, but... what if a server does UID/GID-based permission checks? Then it is a problem, obviously. Xiubo Li (cephfs kernel driver maintainer) asked, why we don't just want to pass mnt_idmap everywhere, including ->lookup. Christian and I came up with arguments, why it's not the best idea to pass idmapping everywhere. [3], [4], [5] [1] https://lore.kernel.org/all/20230807132626.182101-1-aleksandr.mikhalitsyn@xxxxxxxxxxxxx/ [2] https://lore.kernel.org/all/20220104140414.155198-3-brauner@xxxxxxxxxx/ [3] https://lore.kernel.org/lkml/20230609-alufolie-gezaubert-f18ef17cda12@brauner/ [4] https://lore.kernel.org/lkml/20230614-westseite-urlaub-7a5afcf0577a@brauner/ [5] https://lore.kernel.org/lkml/CAEivzxfw1fHO2TFA4dx3u23ZKK6Q+EThfzuibrhA3RKM=ZOYLg@xxxxxxxxxxxxxx/ Kind regards, Alex > Thanks, > Miklos
