From: sashiko-bot@kernel.org
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH v3 1/4] pidfd: restrict task access ioctls to the caller's pid namespace
Date: Sat, 10 Oct 2026 10:27:14 +0000 [thread overview]
Message-ID: <sashiko-outbox-166430@kernel.org> (raw)
In-Reply-To: <20261010-pidfd-get-paths-v3-1-f245440b2b30@black-desk.cn>
> From: Chen Linxuan <me@black-desk.cn>
>
> pidfds can cross pid namespace boundaries: a task may obtain one for a
> process outside of its own pid namespace hierarchy through SO_PASSPIDFD
> or SO_PEERPIDFD, via SCM_RIGHTS, or through file descriptor inheritance.
>
> The namespace ioctls gate access with a ptrace check against the
> target's credentials only. That check does not account for the pid
> namespace relationship between the caller and the target, so a task
> inside a pid namespace can use a pidfd obtained across that boundary to
> acquire namespace file descriptors of a task outside of its hierarchy.
>
> procfs exposes the equivalent information only for tasks visible in the
> reader's pid namespace, and PIDFD_GET_INFO already answers with -EREMOTE
> for targets outside the caller's hierarchy. Extend that policy to the
> namespace ioctls: fail with -EREMOTE unless the target is visible in the
> caller's active pid namespace. Callers in ancestor pid namespaces are
> unaffected.
>
> Unlike PIDFD_GET_INFO, the visibility check is performed after the task
> lookup here, so reaped targets outside of the caller's pid namespace
> hierarchy answer -ESRCH instead of -EREMOTE.
>
> Link: https://lore.kernel.org/all/CAG48ez1T5-tUHVK_iHsgUtWa-inVdrZxA3E-ZCW0iENJvasKfg@mail.gmail.com
> Link: https://lore.kernel.org/all/20260925-gewischt-auftrag-tierzucht-c153cb3f9f74@brauner
> Suggested-by: Jann Horn <jannh@google.com>
> Suggested-by: Christian Brauner <brauner@kernel.org>
> Assisted-by: LLM
> Signed-off-by: Chen Linxuan <me@black-desk.cn>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261010-pidfd-get-paths-v3-0-f245440b2b30@black-desk.cn?part=1
next prev parent reply other threads:[~2026-10-10 10:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 10:20 [PATCH v3 0/4] pidfd: add task path ioctls Chen Linxuan via B4 Relay
2026-10-10 10:20 ` Chen Linxuan
2026-10-10 10:20 ` [PATCH v3 1/4] pidfd: restrict task access ioctls to the caller's pid namespace Chen Linxuan via B4 Relay
2026-10-10 10:20 ` Chen Linxuan
2026-10-10 10:27 ` sashiko-bot [this message]
2026-10-10 10:20 ` [PATCH v3 2/4] fs: Introduce task path helpers Chen Linxuan via B4 Relay
2026-10-10 10:20 ` Chen Linxuan
2026-10-10 10:30 ` sashiko-bot
2026-10-10 10:20 ` [PATCH v3 3/4] pidfd: Use scoped cleanup for task access Chen Linxuan via B4 Relay
2026-10-10 10:20 ` Chen Linxuan
2026-10-10 10:30 ` sashiko-bot
2026-10-10 10:20 ` [PATCH v3 4/4] pidfd: Add task path ioctls Chen Linxuan via B4 Relay
2026-10-10 10:20 ` Chen Linxuan
2026-10-10 10:32 ` sashiko-bot
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=sashiko-outbox-166430@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.