On Tue, Sep 22, 2026 at 4:22 AM Jann Horn <[email protected]> wrote: > > On Wed, Sep 2, 2026 at 8:47 AM Chen Linxuan <[email protected]> wrote: > > On Mon, Aug 31, 2026 at 4:49 PM Christian Brauner <[email protected]> > > wrote: > > > 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 <[email protected]> > > > > --- > > > > > > 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 > > > > One point regarding hidepid: for callers that can pass > > PTRACE_MODE_READ_FSCREDS, hidepid does not provide an additional > > restriction. With hidepid=1 or hidepid=2, has_pid_permissions() falls > > back to ptrace_may_access(..., PTRACE_MODE_READ_FSCREDS), and > > hidepid=ptraceable uses that check directly. In addition, the > > /proc/<pid>/{exe,cwd,root} links independently perform the same > > PTRACE_MODE_READ_FSCREDS check in call_proc_get_link(), regardless of > > the hidepid mode. > > > > So for these specific path lookups, hidepid does not block a caller who > > would already pass the check used by the proposed pidfd ioctls. > > Agreed, I think with regards to hidepid there should be no issue here. > > If I try to come up with scenarios in which this could introduce > additional danger, the main one I can think of would be: A task T1 is > running inside a pid namespace and has a unix domain socket connection > to a task T2 outside the namespace, with both running as the same > EUID; T1 sets SO_PASSPIDFD on its socket to obtain a pidfd pointing to
Does SO_PEERPIDFD matter too? > T2 on the next message sent by T2, then T1 uses that to get access to > the mount namespace of T2. > > Christian, is there some mechanism that already protects against using > something like SO_PASSPIDFD to get a pidfd to a process in a parent > namespace? > Otherwise, should we add something like a "pid_vnr(pid) != 0" check > either in these new operations or in SO_PASSPIDFD? >
