Re: [PATCH 1/3] file: add fd_except cleanup class

[Andreas Gruenbacher]

Christian,

On Wed, Jun 17, 2026 at 3:41 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> On Sun, Jun 07, 2026 at 06:41:34PM +0200, Andreas Gruenbacher wrote:
> > CLASS(fd_except, f)(fd, mask) allows to specify whether to accept or reject
> > O_PATH file descriptors by passing a mode value of 0 or FMODE_PATH rather than
> > using a specific cleanup class for each case (CLASS(fd, f)(fd) or CLASS(fd_raw,
> > f)(fd)).
>
> My main objection to such patches continues to be that it keeps watering
> down the meaning of O_PATH if it continues being usable for performing
> ever more actions including write-like operations like setting extended
> attributes.

I see where you're going, but let me argue that extended attributes
are different from file data. For example, the
"system.posix_acl_access" and "system.posix_acl_default" attributes
are about file permissions. They are an extension of the classical
file mode permission bits which are accessed via stat*() and chmod*(),
operations which accept O_PATH file descriptors today.

The "security.selinux" attribute is in a similar category as
"system.posix_acl_access" and "system.posix_acl_default".

The "trusted.*" namespace is proctected by CAP_SYS_ADMIN, so it's
obviously also not about file data like information.

The "user.*" namespace may appear different because access is guarded
by the file permissions. In that sense, you could say that setting
"user.*" attributes is a bit more like writing to the file. It's still
only arbitrary information attached to the inode itself, though. For
example, operations on "user.*" attributes affect the ctime (when
changing), but never the atime or mtime.

Also, you're clearly aware that the same operations are possible via
"/proc/self/fd/<num>" today, just in a messy way. The exception are
environments that don't make /proc available. It seems fairly bizarre
to me to make O_PATH file descriptors available to environments
restricted in that way in the first place. And that's the only case in
which processes would effectively gain new abilities.

By the way, I forgot to mention previously that this patch set is
related to the following change:

5daeb41a6fc9 ("fchmodat2: add support for AT_EMPTY_PATH")

Thanks,
Andreas