Ever since the introduction of pid namespaces, procfs has had very implicit behaviour surrounding them (the pidns used by a procfs mount is auto-selected based on the mounting process's active pidns, and the pidns itself is basically hidden once the mount has been constructed).
/* pidns mount option for procfs */
This implicit behaviour has historically meant that userspace was required to do some special dances in order to configure the pidns of a procfs mount as desired. Examples include:
* In order to bypass the mnt_too_revealing() check, Kubernetes creates a procfs mount from an empty pidns so that user namespaced containers can be nested (without this, the nested containers would fail to mount procfs). But this requires forking off a helper process because you cannot just one-shot this using mount(2).
* Container runtimes in general need to fork into a container before configuring its mounts, which can lead to security issues in the case of shared-pidns containers (a privileged process in the pidns can interact with your container runtime process). While SUID_DUMP_DISABLE and user namespaces make this less of an issue, the strict need for this due to a minor uAPI wart is kind of unfortunate.
Things would be much easier if there was a way for userspace to just specify the pidns they want. Patch 1 implements a new "pidns" argument which can be set using fsconfig(2):
fsconfig(procfd, FSCONFIG_SET_FD, "pidns", NULL, nsfd); fsconfig(procfd, FSCONFIG_SET_STRING, "pidns", "/proc/self/ns/pid", 0);
or classic mount(2) / mount(8):
// mount -t proc -o pidns=/proc/self/ns/pid proc /tmp/proc mount("proc", "/tmp/proc", "proc", MS_..., "pidns=/proc/self/ns/pid");
The initial security model I have in this RFC is to be as conservative as possible and just mirror the security model for setns(2) -- which means that you can only set pidns=... to pid namespaces that your current pid namespace is a direct ancestor of and you have CAP_SYS_ADMIN privileges over the pid namespace. This fulfils the requirements of container runtimes, but I suspect that this may be too strict for some usecases.
The pidns argument is not displayed in mountinfo -- it's not clear to me what value it would make sense to show (maybe we could just use ns_dname to provide an identifier for the namespace, but this number would be fairly useless to userspace). I'm open to suggestions. Note that PROCFS_GET_PID_NAMESPACE (see below) does at least let userspace get information about this outside of mountinfo.
Note that you cannot change the pidns of an already-created procfs instance. The primary reason is that allowing this to be changed would require RCU-protecting proc_pid_ns(sb) and thus auditing all of fs/proc/* and some of the users in fs/* to make sure they wouldn't UAF the pid namespace. Since creating procfs instances is very cheap, it seems unnecessary to overcomplicate this upfront. Trying to reconfigure procfs this way errors out with -EBUSY.
/* ioctl(PROCFS_GET_PID_NAMESPACE) */
In addition, being able to figure out what pid namespace is being used by a procfs mount is quite useful when you have an administrative process (such as a container runtime) which wants to figure out the correct way of mapping PIDs between its own namespace and the namespace for procfs (using NS_GET_{PID,TGID}_{IN,FROM}_PIDNS). There are alternative ways to do this, but they all rely on ancillary information that third-party libraries and tools do not necessarily have access to.
To make this easier, add a new ioctl (PROCFS_GET_PID_NAMESPACE) which can be used to get a reference to the pidns that a procfs is using.
It's not quite clear what is the correct security model for this API, but the current approach I've taken is to:
* Make the ioctl only valid on the root (meaning that a process without access to the procfs root -- such as only having an fd to a procfs file or some open_tree(2)-like subset -- cannot use this API).
* Require that the process requesting either has access to /proc/1/ns/pid anyway (i.e. has ptrace-read access to the pidns pid1), has CAP_SYS_ADMIN access to the pidns (i.e. has administrative access to it and can join it if they had a handle), or is in a pidns that is a direct ancestor of the target pidns (i.e. all of the pids are already visible in the procfs for the current process's pidns).
The security model for this is a little loose, as it seems to me that all of the cases mentioned are valid cases to allow access, but I'm open to suggestions for whether we need to make this stricter or looser.
Signed-off-by: Aleksa Sarai cyphar@cyphar.com --- Changes in v3: - Disallow changing pidns for existing procfs instances, as we'd probably have to RCU-protect everything that touches the pinned pidns reference. - Improve tests with slightly nicer ASSERT_ERRNO* macros. - v2: https://lore.kernel.org/r/20250723-procfs-pidns-api-v2-0-621e7edd8e40@cyphar.com
Changes in v2: - #ifdef CONFIG_PID_NS - Improve cover letter wording to make it clear we're talking about two separate features with different permission models. [Andy Lutomirski] - Fix build warnings in pidns_is_ancestor() patch. [kernel test robot] - v1: https://lore.kernel.org/r/20250721-procfs-pidns-api-v1-0-5cd9007e512d@cyphar.com
--- Aleksa Sarai (4): pidns: move is-ancestor logic to helper procfs: add "pidns" mount option procfs: add PROCFS_GET_PID_NAMESPACE ioctl selftests/proc: add tests for new pidns APIs
Documentation/filesystems/proc.rst | 12 ++ fs/proc/root.c | 156 +++++++++++++++++- include/linux/pid_namespace.h | 9 ++ include/uapi/linux/fs.h | 3 + kernel/pid_namespace.c | 23 ++- tools/testing/selftests/proc/.gitignore | 1 + tools/testing/selftests/proc/Makefile | 1 + tools/testing/selftests/proc/proc-pidns.c | 252 ++++++++++++++++++++++++++++++ 8 files changed, 441 insertions(+), 16 deletions(-) --- base-commit: 66639db858112bf6b0f76677f7517643d586e575 change-id: 20250717-procfs-pidns-api-8ed1583431f0
Best regards,