On Thu, Aug 29, 2024 at 2:30 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Thu, 29 Aug 2024 at 14:08, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > Fwiw, that's what the patchset is doing. It's only supported if the > > server sets "default_permissions". > > My specific issue is with FUSE_EXT_OWNER_UID_GID, which I think is > unnecessary. Just fill the header with the mapped uid/gid values, > which most servers already use for creating the file with the correct > st_uid/st_gid and not for checking permission. When the mapped values > are unavailable, set the uid/gid in the header -1. Should be better > than sending nonsense values to userspace, no? Hi Miklos, yeah, we have a discussion like that while discussing cephfs idmapped mounts. And yes, it's a really good question and it's not obvious at all which solution is the best. ( I believe that I have replied on that question already there: https://lore.kernel.org/all/CAEivzxeva5ipjihSrMa4u=uk9sDm9DNg9cLoYg0O6=eU2jLNQQ@xxxxxxxxxxxxxx/ ) A main argument against mapping uid/gid values in fuse header is consistency. We can map these values in symlink/mknod/mkdir/create/tmpfile. But we don't have access to idmapping information in lookup, read, write, etc. What should we do for these inode operations then? Send an unmapped uid/gid? But then it is an inconsistency - in one inode ops we have mapped values, in another ones - we have unmapped ones. >When the mapped values > are unavailable, set the uid/gid in the header -1. Should be better > than sending nonsense values to userspace, no? So, your point is to set uid/gid to -1 for FUSE_{READ,WRITE,LOOKUP,RELEASE,...}? Kind regards, Alex > > Thanks, > Miklos
