On Thu, 2011-06-16 at 13:54 -0400, Bryan Donlan wrote: > On Wed, Jun 15, 2011 at 10:55, Greg Kurz <gkurz@xxxxxxxxxx> wrote: > > Since pid namespaces were introduced, there's a recurring demand: how one > > can correlate a pid from a child pid ns with a pid from a parent pid ns ? > > The need arises in the LXC community when one wants to send a signal from > > the host (aka. init_pid_ns context) to a container process for which one > > only knows the pid inside the container. > > > > In the future, this should be achievable thanks to Eric Biederman's setns() > > syscall but there's still some work to be done to support pid namespaces: > > > > https://lkml.org/lkml/2011/5/21/162 > > > > As stated by Serge Hallyn in: > > > > http://sourceforge.net/mailarchive/message.php?msg_id=27424447 > > > > "There is nothing that gives you a 100% guaranteed correct race-free > > correspondence right now. You can look under /proc/<pid>/root/proc/ to > > see the pids valid in the container, and you can relate output of > > lxc-ps --forest to ps --forest output. But nothing under /proc that I > > know of tells you "this task is the same as that task". You can't > > even look at /proc/<pid> inode numbers since they are different > > filesystems for each proc mount." > > > > This patch adds a single line to /proc/self/status. Provided one has kept > > track of its container tasks (with a cgroup like liblxc does for example), > > he may correlate global pids and container pids. This is still racy but > > definitely easier than what we have today. > > Although getting the in-namespace PID is a useful thing, wouldn't a > truly race-free API be preferable? Any access by PID has the race > condition in which the target process could die, and its PID get > recycled between retrieving the PID and doing something with it. Well the PID is a racy construct when used by another task than the parent... fortunately, most userland code can cope with it ! :) > Perhaps a file-descriptor API would be better, such as something like > this: > > int openpid(int id, int flags); > int rt_sigqueueinfo_fd(int process_fd, int sig, siginfo_t *info); > int sigqueue_fd(int process_fd, int sig, const union sigval value); // > glibc wrapper > The race still exists: openpid() is being passed a PID... Only the parent can legitimately know that this PID identifies a specific unwaited child. > The opened process FD could be passed across a unix domain socket to a > process outside the namespace, which could then send signals without > knowing the in-namespace PID. This same API can be easily extended to > cover other syscalls which may require PIDs as well. Indeed, the idea of not exposing a PID from another namespace sounds nice. -- Gregory Kurz gkurz@xxxxxxxxxx Software Engineer @ IBM/Meiosys http://www.ibm.com Tel +33 (0)534 638 479 Fax +33 (0)561 400 420 "Anarchy is about taking complete responsibility for yourself." Alan Moore. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
