Re: [PATCH v2 0/3] pidfd: add task path ioctls
From: Christian Brauner <brauner@kernel.org>
Date: 2026-08-31 08:49:48
Also in:
linux-fsdevel, linux-mm, linux-security-module, lkml
On 2026-08-31 10:59 +0800, Chen Linxuan wrote:
Obtaining a target task's executable, working directory, or root currently requires walking procfs symlinks such as /proc/<pid>/exe, /proc/<pid>/cwd, and /proc/<pid>/root. That makes the operation depend on procfs being mounted and visible to the caller, even when it already holds a pidfd for the target. This series adds PIDFD_GET_EXE, PIDFD_GET_CWD, and PIDFD_GET_ROOT. Each ioctl takes no argument and returns a close-on-exec O_PATH file descriptor referencing the corresponding task path. The new ioctls use the same ptrace permission check and nonzero-argument rejection as the existing pidfd namespace ioctls. The target task is sampled while holding its exec_update_lock. This keeps the access decision and the task-state read in the same exec critical section, preventing a concurrent execve() from changing the credentials or target state between the check and the use. The first patch factors out helpers for acquiring referenced task paths and reuses them in procfs and AppArmor. The second patch introduces scoped cleanup for privileged pidfd task access and separates namespace lookup from namespace fd creation. The final patch uses these pieces to implement the three new ioctls. Signed-off-by: Chen Linxuan <redacted> ---
I really have difficulties forming an opinion on this. So this sounds very useful but it has implications. Right now, pidfd ioctls are available even in situations where the task in question would not be accessible via procfs, e.g., when procfs is mounted with "hidepid" options or similar. So this would expand the surface of operations you could potentially do. But again, I do think it is actually useful. Adding Jann.