linux-kernel - O_CLOEXEC use for OPEN_TREE

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-next>] [day] [month] [year] [list]

Message-ID: <lhupl7dcf0o.fsf@oldenburg.str.redhat.com>
Date: Tue, 13 Jan 2026 23:40:55 +0100
From: Florian Weimer <fweimer@...hat.com>
To: linux-fsdevel@...r.kernel.org
Cc: linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
 Al Viro <viro@...iv.linux.org.uk>,
 David Howells <dhowells@...hat.com>, DJ Delorie <dj@...hat.com>
Subject: O_CLOEXEC use for OPEN_TREE_CLOEXEC

In <linux/mount.h>, we have this:

#define OPEN_TREE_CLOEXEC      O_CLOEXEC       /* Close the file on execve() */

This causes a few pain points for us to on the glibc side when we mirror
this into <linux/mount.h> becuse O_CLOEXEC is defined in <fcntl.h>,
which is one of the headers that's completely incompatible with the UAPI
headers.

The reason why this is painful is because O_CLOEXEC has at least three
different values across architectures: 0x80000, 0x200000, 0x400000

Even for the UAPI this isn't ideal because it effectively burns three
open_tree flags, unless the flags are made architecture-specific, too.

Thanks,
Florian