On 24.01.2017 00:49, Alban Crequy wrote: > On 14 January 2017 at 15:15, Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> 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 <ktkhai@xxxxxxxxxxxxx> > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
