From: Alejandro Colomar <alx@kernel.org>
To: Matthieu Buffet <matthieu@buffet.re>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH v3 2/2] man/man7/pid_namespaces.7: Add setns restriction and reasoning
Date: Wed, 13 May 2026 13:41:46 +0200 [thread overview]
Message-ID: <agRjUNiEyfvDxRl0@devuan> (raw)
In-Reply-To: <20260513083339.27911-2-matthieu@buffet.re>
[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]
[CC += linux-man@]
Hi Matthieu,
(You forgot to CC the list.)
On 2026-05-13T10:33:39+0200, Matthieu Buffet wrote:
> The logical implication between PID namespaces being readonly after
> process creation and process trees needing to loosely mirror PID
> namespaces is not trivial to follow. Part of that implication is
> implicit: since PID namespace membership is readonly, one has to use
> fork() or one of its variants to "change" PID namespace, and these APIs
> need to return a valid child PID in the parent namespace. The
> consequence could also be made more explicit (setns() will fail on
> non-descendant PID namespaces) while explaining how this is implemented.
>
> Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
I've applied the patch. Thanks!
Cheers,
Alex
> ---
> man/man7/pid_namespaces.7 | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/man/man7/pid_namespaces.7 b/man/man7/pid_namespaces.7
> index b19afd505..c4a4a2723 100644
> --- a/man/man7/pid_namespaces.7
> +++ b/man/man7/pid_namespaces.7
> @@ -211,8 +211,12 @@ which would break many applications and libraries.
> To put things another way:
> a process's PID namespace membership is determined when the process is created
> and cannot be changed thereafter.
> -Among other things,
> -this means that
> +.P
> +Because of this,
> +and because system calls to create a process
> +in another namespace
> +need to return a meaningful new PID
> +in the namespace of their caller,
> the parental relationship between processes
> loosely mirrors
> the parental relationship between PID namespaces:
> @@ -220,6 +224,15 @@ the parent of a process
> is either in the same namespace
> or resides in an ancestor PID namespace
> (immediate parent or not).
> +This is enforced by the design of
> +.BR clone (2)
> +and
> +.BR unshare (2),
> +while
> +.BR setns (2)
> +is restricted to only accept
> +the current PID namespace
> +and its descendants.
> .P
> A process may call
> .BR unshare (2)
> --
> 2.47.3
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-05-13 11:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <75614ec3-0def-4cdd-b45c-17d21cf8357b@buffet.re>
[not found] ` <20260513083339.27911-1-matthieu@buffet.re>
2026-05-13 11:40 ` [PATCH v3 1/2] man/man7/pid_namespaces.7: Fix requirements on namespace+process trees Alejandro Colomar
[not found] ` <20260513083339.27911-2-matthieu@buffet.re>
2026-05-13 11:41 ` Alejandro Colomar [this message]
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=agRjUNiEyfvDxRl0@devuan \
--to=alx@kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=matthieu@buffet.re \
/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.