On 8/4/25 10:45 PM, Aleksa Sarai wrote: > /proc has historically had very opaque semantics about PID namespaces, > which is a little unfortunate for container runtimes and other programs > that deal with switching namespaces very often. One common issue is that > of converting between PIDs in the process's namespace and PIDs in the > namespace of /proc. > > In principle, it is possible to do this today by opening a pidfd with > pidfd_open(2) and then looking at /proc/self/fdinfo/$n (which will > contain a PID value translated to the pid namespace associated with that > procfs superblock). However, allocating a new file for each PID to be > converted is less than ideal for programs that may need to scan procfs, > and it is generally useful for userspace to be able to finally get this > information from procfs. > > So, add a new API to get the pid namespace of a procfs instance, in the > form of an ioctl(2) you can call on the root directory of said procfs. > The returned file descriptor will have O_CLOEXEC set. This acts as a > sister feature to the new "pidns" mount option, finally allowing > userspace full control of the pid namespaces associated with procfs > instances. > > The permission model for this is a bit looser than that of the "pidns" > mount option (and also setns(2)) because /proc/1/ns/pid provides the > same information, so as long as you have access to that magic-link (or > something equivalently reasonable such as being in an ancestor pid > namespace) it makes sense to allow userspace to grab a handle. Ideally > we would check for ptrace-read access against all processes in the pidns > (which is very likely to be true for at least one process, as > SUID_DUMP_DISABLE is cleared on exec(2) and is rarely set by most > programs), but this would obviously not scale. > > setns(2) will still have their own permission checks, so being able to > open a pidns handle doesn't really provide too many other capabilities. > > Signed-off-by: Aleksa Sarai <cyphar@xxxxxxxxxx> > --- > Documentation/filesystems/proc.rst | 4 +++ > fs/proc/root.c | 68 ++++++++++++++++++++++++++++++++++++-- > include/uapi/linux/fs.h | 4 +++ > 3 files changed, 74 insertions(+), 2 deletions(-) > > diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h > index 0bd678a4a10e..68e65e6d7d6b 100644 > --- a/include/uapi/linux/fs.h > +++ b/include/uapi/linux/fs.h > @@ -435,8 +435,12 @@ typedef int __bitwise __kernel_rwf_t; > RWF_APPEND | RWF_NOAPPEND | RWF_ATOMIC |\ > RWF_DONTCACHE) > > +/* This matches XSDFEC_MAGIC, so we need to allocate subvalues carefully. */ > #define PROCFS_IOCTL_MAGIC 'f' > > +/* procfs root ioctls */ > +#define PROCFS_GET_PID_NAMESPACE _IO(PROCFS_IOCTL_MAGIC, 32) Since the _IO() nr here is 32, Documentation/userspace-api/ioctl/ioctl-number.rst should be updated like: -'f' 00-0F linux/fs.h conflict! +'f' 00-1F linux/fs.h conflict! (17 is already used for PROCFS_IOCTL_MAGIC somewhere else, so that probably should have update the Doc/rst file.) > + > /* Pagemap ioctl */ > #define PAGEMAP_SCAN _IOWR(PROCFS_IOCTL_MAGIC, 16, struct pm_scan_arg) > > Thanks. -- ~Randy
