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: <CAJfpegsqPz+8iDVZmmSHn09LZ9fMwyYzb+Kib4258y8jSafsYQ@mail.gmail.com>
Date: Thu, 29 Aug 2024 10:24:42 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
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 Thu, 18 Jul 2024 at 21:12, Aleksandr Mikhalitsyn
<aleksandr.mikhalitsyn@...onical.com> wrote:

> 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.

Is it even sensible to do UID/GID-based permission checks in the
server if idmapping is enabled?

If not, then we should just somehow disable that configuration (i.e.
by the server having to opt into idmapping), and then we can just use
the in_h.[ugi]d for creates, no?

Thanks,
Miklos