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: <CAEivzxeva5ipjihSrMa4u=uk9sDm9DNg9cLoYg0O6=eU2jLNQQ@mail.gmail.com>
Date: Thu, 18 Jul 2024 21:12:07 +0200
From: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: mszeredi@...hat.com, brauner@...nel.org, 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 Tue, Mar 5, 2024 at 3:38 PM Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Mon, 8 Jan 2024 at 13:10, Alexander Mikhalitsyn
> <aleksandr.mikhalitsyn@...onical.com> 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@canonical.com/
[2] https://lore.kernel.org/all/20220104140414.155198-3-brauner@kernel.org/
[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@mail.gmail.com/

Kind regards,
Alex

> Thanks,
> Miklos