lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Jan 2017 22:49:14 +0100
From:   Alban Crequy <>
To:     Kirill Tkhai <>
Cc:     Andrey Vagin <>,
        "" <>,,
        "Eric W. Biederman" <>,
        Cyrill Gorcunov <>,
        Alexander Viro <>,
        Michael Kerrisk-manpages <>,
        Linux API <>
Subject: Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace

On 14 January 2017 at 15:15, Kirill Tkhai <> 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 <>

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."

Powered by blists - more mailing lists