From: Jeff Layton <jlayton@kernel.org>
To: Jori Koolstra <jkoolstra@xs4all.nl>,
Chuck Lever <chuck.lever@oracle.com>,
Alexander Aring <alex.aring@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Shuah Khan <shuah@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Aleksa Sarai <cyphar@cyphar.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Ethan Tidmore <ethantidmore06@gmail.com>,
NeilBrown <neil@brown.name>, Oleg Nesterov <oleg@redhat.com>,
Penglei Jiang <superman.xpt@gmail.com>,
Kees Cook <kees@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@kernel.org>,
Amir Goldstein <amir73il@gmail.com>,
Namjae Jeon <linkinjeon@kernel.org>,
Mateusz Guzik <mjguzik@gmail.com>,
Wei Yang <richard.weiyang@gmail.com>,
Bala-Vignesh-Reddy <reddybalavignesh9979@gmail.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/3] vfs: add support for empty path to openat2(2)
Date: Mon, 30 Mar 2026 08:12:33 -0400 [thread overview]
Message-ID: <ecc86514cde4732995d9f50b9f5071fbb1f675e4.camel@kernel.org> (raw)
In-Reply-To: <20260326182033.1809567-2-jkoolstra@xs4all.nl>
On Thu, 2026-03-26 at 19:20 +0100, Jori Koolstra wrote:
> To get an operable version of an O_PATH file descriptor, it is possible
> to use openat(fd, ".", O_DIRECTORY) for directories, but other files
> currently require going through open("/proc/<pid>/fd/<nr>"), which
> depends on a functioning procfs.
>
> This patch adds the OPENAT2_EMPTY_PATH flag to openat2(2). If passed,
> LOOKUP_EMPTY is set at path resolve time.
>
> Note: This implies that you cannot rely anymore on disabling procfs from
> being mounted (e.g. inside a container without procfs mounted and with
> CAP_SYS_ADMIN dropped) to prevent O_PATH fds from being re-opened
> read-write.
>
> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> ---
> fs/fcntl.c | 4 ++--
> fs/open.c | 11 +++++------
> include/linux/fcntl.h | 5 ++++-
> include/uapi/linux/openat2.h | 4 ++++
> 4 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index beab8080badf..d9ae3c71edfe 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -1169,8 +1169,8 @@ static int __init fcntl_init(void)
> * Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
> * is defined as O_NONBLOCK on some platforms and not on others.
> */
> - BUILD_BUG_ON(20 - 1 /* for O_RDONLY being 0 */ !=
> - HWEIGHT32(
> + BUILD_BUG_ON(21 - 1 /* for O_RDONLY being 0 */ !=
> + HWEIGHT64(
> (VALID_OPEN_FLAGS & ~(O_NONBLOCK | O_NDELAY)) |
> __FMODE_EXEC));
>
> diff --git a/fs/open.c b/fs/open.c
> index 91f1139591ab..e019ddecc73c 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -1160,12 +1160,12 @@ struct file *kernel_file_open(const struct path *path, int flags,
> EXPORT_SYMBOL_GPL(kernel_file_open);
>
> #define WILL_CREATE(flags) (flags & (O_CREAT | __O_TMPFILE))
> -#define O_PATH_FLAGS (O_DIRECTORY | O_NOFOLLOW | O_PATH | O_CLOEXEC)
> +#define O_PATH_FLAGS (O_DIRECTORY | O_NOFOLLOW | O_PATH | O_CLOEXEC | OPENAT2_EMPTY_PATH)
>
> inline struct open_how build_open_how(int flags, umode_t mode)
> {
> struct open_how how = {
> - .flags = flags & VALID_OPEN_FLAGS,
> + .flags = ((unsigned int) flags) & VALID_OPEN_FLAGS,
> .mode = mode & S_IALLUGO,
> };
>
> @@ -1185,9 +1185,6 @@ inline int build_open_flags(const struct open_how *how, struct open_flags *op)
> int lookup_flags = 0;
> int acc_mode = ACC_MODE(flags);
>
> - BUILD_BUG_ON_MSG(upper_32_bits(VALID_OPEN_FLAGS),
> - "struct open_flags doesn't yet handle flags > 32 bits");
> -
> /*
> * Strip flags that aren't relevant in determining struct open_flags.
> */
> @@ -1281,6 +1278,8 @@ inline int build_open_flags(const struct open_how *how, struct open_flags *op)
> lookup_flags |= LOOKUP_DIRECTORY;
> if (!(flags & O_NOFOLLOW))
> lookup_flags |= LOOKUP_FOLLOW;
> + if (flags & OPENAT2_EMPTY_PATH)
> + lookup_flags |= LOOKUP_EMPTY;
>
> if (how->resolve & RESOLVE_NO_XDEV)
> lookup_flags |= LOOKUP_NO_XDEV;
> @@ -1362,7 +1361,7 @@ static int do_sys_openat2(int dfd, const char __user *filename,
> if (unlikely(err))
> return err;
>
> - CLASS(filename, name)(filename);
> + CLASS(filename_flags, name)(filename, op.lookup_flags);
> return FD_ADD(how->flags, do_file_open(dfd, name, &op));
> }
>
> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
> index a332e79b3207..d1bb87ff70e3 100644
> --- a/include/linux/fcntl.h
> +++ b/include/linux/fcntl.h
> @@ -7,10 +7,13 @@
>
> /* List of all valid flags for the open/openat flags argument: */
> #define VALID_OPEN_FLAGS \
> + /* lower 32-bit flags */ \
> (O_RDONLY | O_WRONLY | O_RDWR | O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | \
> O_APPEND | O_NDELAY | O_NONBLOCK | __O_SYNC | O_DSYNC | \
> FASYNC | O_DIRECT | O_LARGEFILE | O_DIRECTORY | O_NOFOLLOW | \
> - O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE)
> + O_NOATIME | O_CLOEXEC | O_PATH | __O_TMPFILE | \
> + /* upper 32-bit flags (openat2(2) only) */ \
> + OPENAT2_EMPTY_PATH)
>
> /* List of all valid flags for the how->resolve argument: */
> #define VALID_RESOLVE_FLAGS \
> diff --git a/include/uapi/linux/openat2.h b/include/uapi/linux/openat2.h
> index a5feb7604948..c34f32e6fa96 100644
> --- a/include/uapi/linux/openat2.h
> +++ b/include/uapi/linux/openat2.h
> @@ -40,4 +40,8 @@ struct open_how {
> return -EAGAIN if that's not
> possible. */
>
> +/* openat2(2) exclusive flags are defined in the upper 32 bits of
> + open_how->flags */
> +#define OPENAT2_EMPTY_PATH 0x100000000 /* (1ULL << 32) */
> +
> #endif /* _UAPI_LINUX_OPENAT2_H */
Looks sane to me. Can this be merged apart from the rest of the series?
It doesn't seem like the transitive stuff is dependent on this.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-03-30 12:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 18:20 [RFC PATCH v2 0/3] vfs: transitive upgrade restrictions for fds Jori Koolstra
2026-03-26 18:20 ` [RFC PATCH v2 1/3] vfs: add support for empty path to openat2(2) Jori Koolstra
2026-03-27 6:26 ` Aleksa Sarai
2026-03-29 22:13 ` Jori Koolstra
2026-03-30 12:12 ` Jeff Layton [this message]
2026-03-30 14:17 ` Jori Koolstra
2026-04-01 12:23 ` Aleksa Sarai
2026-04-01 20:49 ` Jori Koolstra
2026-03-26 18:20 ` [RFC PATCH v2 2/3] vfs: transitive upgrade restrictions for fds Jori Koolstra
2026-03-27 6:20 ` Aleksa Sarai
2026-03-29 21:54 ` Jori Koolstra
2026-04-01 12:15 ` Aleksa Sarai
2026-03-26 18:20 ` [RFC PATCH v2 3/3] selftest: add tests for OPENAT2_EMPTY_PATH and allowed_upgrades Jori Koolstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ecc86514cde4732995d9f50b9f5071fbb1f675e4.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alex.aring@gmail.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=cyphar@cyphar.com \
--cc=david@kernel.org \
--cc=ethantidmore06@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=jkoolstra@xs4all.nl \
--cc=kees@kernel.org \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mjguzik@gmail.com \
--cc=neil@brown.name \
--cc=oleg@redhat.com \
--cc=reddybalavignesh9979@gmail.com \
--cc=richard.weiyang@gmail.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=superman.xpt@gmail.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome