All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alban Crequy <alban.crequy@gmail.com>
To: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Andrey Vagin <avagin@openvz.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace
Date: Mon, 23 Jan 2017 22:49:14 +0100	[thread overview]
Message-ID: <CAMXgnP7gs_SXTj3yLFSM9DVfmN09m7q0hYQN-9oa3aV4eYgw5w@mail.gmail.com> (raw)
In-Reply-To: <148440329770.30622.16593902895676160550.stgit@localhost.localdomain>

On 14 January 2017 at 15:15, Kirill Tkhai <ktkhai@virtuozzo.com> 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@virtuozzo.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Alban Crequy <alban.crequy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
Cc: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Cyrill Gorcunov
	<gorcunov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Michael Kerrisk-manpages
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace
Date: Mon, 23 Jan 2017 22:49:14 +0100	[thread overview]
Message-ID: <CAMXgnP7gs_SXTj3yLFSM9DVfmN09m7q0hYQN-9oa3aV4eYgw5w@mail.gmail.com> (raw)
In-Reply-To: <148440329770.30622.16593902895676160550.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>

On 14 January 2017 at 15:15, Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org> 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-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>

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

  parent reply	other threads:[~2017-01-23 21:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-14 14:14 [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Kirill Tkhai
2017-01-14 14:15 ` [PATCH 2/2] pidns: Expose task pid_ns_for_children to userspace Kirill Tkhai
2017-01-17 20:00   ` Andrei Vagin
2017-01-17 20:00     ` Andrei Vagin
2017-01-23 21:49   ` Alban Crequy [this message]
2017-01-23 21:49     ` Alban Crequy
2017-01-24  8:35     ` Kirill Tkhai
2017-01-24  8:35       ` Kirill Tkhai
2017-01-30 15:10   ` Kirill Tkhai
2017-01-16  8:18 ` [PATCH 1/2] ns: Allow ns_entries to have custom symlink content Cyrill Gorcunov

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=CAMXgnP7gs_SXTj3yLFSM9DVfmN09m7q0hYQN-9oa3aV4eYgw5w@mail.gmail.com \
    --to=alban.crequy@gmail.com \
    --cc=avagin@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@openvz.org \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.