From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <148440329770.30622.16593902895676160550.stgit@localhost.localdomain> References: <148440326011.30622.12833059348082223242.stgit@localhost.localdomain> <148440329770.30622.16593902895676160550.stgit@localhost.localdomain> From: Alban Crequy Date: Mon, 23 Jan 2017 22:49:14 +0100 Message-ID: Subject: Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace To: Kirill Tkhai Cc: Andrey Vagin , "linux-kernel@vger.kernel.org" , linux-fsdevel@vger.kernel.org, "Eric W. Biederman" , Cyrill Gorcunov , Alexander Viro , Michael Kerrisk-manpages , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: 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."