linux-kernel - Re: [PATCH v1 2/9] fs/fuse: add FUSE_OWNER_UID_GID

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEivzxdPmLZ7rW1aUtqxzJEP0_ScGTnP2oRhJO2CRWS8fb3OLQ@mail.gmail.com>
Date: Thu, 29 Aug 2024 16:39:29 +0200
From: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Christian Brauner <brauner@...nel.org>, mszeredi@...hat.com, stgraber@...raber.org, 
	linux-fsdevel@...r.kernel.org, Seth Forshee <sforshee@...nel.org>, 
	Amir Goldstein <amir73il@...il.com>, Bernd Schubert <bschubert@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/9] fs/fuse: add FUSE_OWNER_UID_GID_EXT extension

On Thu, Aug 29, 2024 at 2:30 PM Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Thu, 29 Aug 2024 at 14:08, Christian Brauner <brauner@...nel.org> 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@mail.gmail.com/
)

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