# Re: \[PATCH 2/2\] pidns: Expose task pid\_ns\_for\_children to userspace

- List: linux-api
- 2 messages, 2 authors
- Page: https://ratatoskr.run/linux-api/2017/01/116869/t

## Re: \[PATCH 2/2\] pidns: Expose task pid\_ns\_for\_children to userspace

- From: Alban Crequy \<hidden\>
- Date: 2017-01-23 21:49:14 
- Message: https://ratatoskr.run/linux-api/2017/01/116869.md

```text
On 14 January 2017 at 15:15, Kirill Tkhai [ref] wrote:
> For correct checkpointing/restoring of a task from userspace
> it's need to know the task's pid_ns_for_children. Currently,
> there is no a sane way to do that (the only possible trick
> is to force the task create a new child and to analize the
> child's /proc/[pid]/ns/pid link, that is performance-stupid).
>
> The patch exposes pid_ns_for_children to ns directory
> in standard way with the name "pid_for_children":
>
> ~# ls /proc/5531/ns -l | grep pid
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836]
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286]
>
> Signed-off-by: Kirill Tkhai <redacted>

What's happening if a process, after unsharing CLONE_NEWPID, does not
fork but instead let another process open the new "pid_for_children"
and then setns()+fork()? Is that other process allowed to create the
"pid 1" in the new pid namespaces? Is that also allowed if the other
process lives in a sibling pid namespace? If so, that would break what
pid_namespaces(7) says:

    "the parental relationship between processes mirrors the parental
     relationship between PID namespaces: the parent of a process is
     either in the same namespace or resides in the immediate parent
     PID namespace."
```

## Re: \[PATCH 2/2\] pidns: Expose task pid\_ns\_for\_children to userspace

- From: Kirill Tkhai \<hidden\>
- Date: 2017-01-24 08:35:17 
- Message: https://ratatoskr.run/linux-api/2017/01/116868.md

```text
On 24.01.2017 00:49, Alban Crequy wrote:
> On 14 January 2017 at 15:15, Kirill Tkhai [ref] wrote:
>> For correct checkpointing/restoring of a task from userspace
>> it's need to know the task's pid_ns_for_children. Currently,
>> there is no a sane way to do that (the only possible trick
>> is to force the task create a new child and to analize the
>> child's /proc/[pid]/ns/pid link, that is performance-stupid).
>>
>> The patch exposes pid_ns_for_children to ns directory
>> in standard way with the name "pid_for_children":
>>
>> ~# ls /proc/5531/ns -l | grep pid
>> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836]
>> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286]
>>
>> Signed-off-by: Kirill Tkhai <redacted>
> 
> What's happening if a process, after unsharing CLONE_NEWPID, does not
> fork but instead let another process open the new "pid_for_children"
> and then setns()+fork()? Is that other process allowed to create the
> "pid 1" in the new pid namespaces? Is that also allowed if the other
> process lives in a sibling pid namespace? If so, that would break what
> pid_namespaces(7) says:
> 
>     "the parental relationship between processes mirrors the parental
>      relationship between PID namespaces: the parent of a process is
>      either in the same namespace or resides in the immediate parent
>      PID namespace."
> 

You can setns() on a pid_ns only if your active pid_ns is a (grand)parent
for the target pid_ns. So, the situation you described is not possible.
See pidns_install() for the details.
```