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

[Christian Brauner]

On Wed, Jun 17, 2026 at 04:50:00PM +0200, Andreas Gruenbacher wrote:
> 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

Yes, very aware and I hate it. I wish we had upgrade masks but that's
is very very hairy work. :)

> 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")

Yeah, I did merge that because of fchown*() parity. Let me sit on it for
a few days to mull it over.