Linux filesystem development
 help / color / mirror / Atom feed
From: Tao Cui <cui.tao@linux.dev>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tycho Andersen <tycho@tycho.pizza>,
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>,
	Andrei Vagin <avagin@gmail.com>,
	cui.tao@linux.dev, Tao Cui <cuitao@kylinos.cn>
Subject: [PATCH 0/2] nsfs: gate pid-translation ioctls behind ptrace read access
Date: Fri, 30 Oct 2026 21:04:20 +0800	[thread overview]
Message-ID: <20261030130422.738277-1-cui.tao@linux.dev> (raw)

From: Tao Cui <cuitao@kylinos.cn>

The four NS_GET_{PID,TGID}_{FROM,IN}_PIDNS ioctls on nsfs descriptors
only check that the fd refers to a PID namespace; they never check
whether the caller may inspect the task being looked up.  An nsfs fd
is freely transferable (SCM_RIGHTS), so an unprivileged process that
receives one - the way container runtimes and LXCFS hand namespace
fds to less privileged helpers - can use these ioctls as a task
enumeration oracle across pid namespaces, bypassing the ptrace-gated
/proc files.  With hidepid=2 on the host, a measured run of this
scenario resolved every live container pid (the init and its
children) to its host pid.

Patch 1 checks ptrace_may_access(PTRACE_MODE_READ_FSCREDS) on the
looked-up task.  The errno (-EACCES) and the check itself mirror
proc_ns_get_link()/proc_ns_readlink() (fs/proc/namespaces.c) and
PIDFD_GET_*_NAMESPACE (fs/pidfs.c).  The legitimate holder - the task
itself, or a privileged runtime daemon such as LXCFS - is
unaffected.  The check is per-call on the target task, not at fd
installation: checking at open time would authorize every current and
future task of that namespace at once, which is exactly what must not
be granted.

Two residual behaviours are worth stating explicitly: ESRCH is still
returned before the permission check, so pid existence remains a
1-bit signal - the same residual pidfs and /proc carry today; and
with hidepid=0, translating a same-uid non-dumpable task now
fails, aligning nsfs with ptrace-gated /proc files.

Patch 2 adds a selftest with four checks: root translation of the
container init (lxcfs path), full denial for an unprivileged
receiver of the fd on all four ioctls in both translation
directions, a root-side re-check, and same-task translation.
Test 2 is expected to fail on trees without patch 1.

Tao Cui (2):
  nsfs: require ptrace read access for pid translation ioctls
  selftests: namespaces: test nsfs pid-translation access gate


 fs/nsfs.c                                     |  14 +
 tools/testing/selftests/namespaces/.gitignore |   1 +
 tools/testing/selftests/namespaces/Makefile   |   1 +
 .../namespaces/nsfs_pid_translation_test.c    | 399 ++++++++++++++++++
 4 files changed, 415 insertions(+)
 create mode 100644 tools/testing/selftests/namespaces/nsfs_pid_translation_test.c

-- 
2.43.0


             reply	other threads:[~2026-10-30 13:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 13:04 Tao Cui [this message]
2026-10-30 13:04 ` [PATCH 1/2] nsfs: require ptrace read access for pid translation ioctls Tao Cui
2026-10-30 13:04 ` [PATCH 2/2] selftests/namespaces: test nsfs pid-translation access gate Tao Cui

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=20261030130422.738277-1-cui.tao@linux.dev \
    --to=cui.tao@linux.dev \
    --cc=aleksandr.mikhalitsyn@canonical.com \
    --cc=avagin@gmail.com \
    --cc=brauner@kernel.org \
    --cc=cuitao@kylinos.cn \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tycho@tycho.pizza \
    /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