linux-kernel - Re: [PATCH] Introduce ActivePid: in /proc/self/status (v2, was Vpid:)

lists.openwall.net		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 linux-cve-announce 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:	Thu, 16 Jun 2011 13:54:57 -0400
From:	Bryan Donlan <bdonlan@...il.com>
To:	Greg Kurz <gkurz@...ibm.com>
Cc:	akpm@...ux-foundation.org, containers@...ts.osdl.org,
	linux-kernel@...r.kernel.org, serge@...lyn.com,
	daniel.lezcano@...e.fr, ebiederm@...ssion.com, oleg@...hat.com,
	xemul@...nvz.org, Cedric Le Goater <clg@...ibm.com>
Subject: Re: [PATCH] Introduce ActivePid: in /proc/self/status (v2, was Vpid:)

On Wed, Jun 15, 2011 at 10:55, Greg Kurz <gkurz@...ibm.com> 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.
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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/