From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Cc: Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: Mapping between host & container PIDs ?
Date: Tue, 27 Nov 2012 07:50:35 -0600 [thread overview]
Message-ID: <87vccrm9xw.fsf@xmission.com> (raw)
In-Reply-To: <20121127133609.GC3727@sergelap> (Serge Hallyn's message of "Tue, 27 Nov 2012 07:36:09 -0600")
Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:
> Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> I'm trying to find out if there is a way to map between host and container
>> PIDs, at minimum in the host -> container direction. My use case is to be
>> able to kill processes associated with a container, based on the host PID,
>> in a race free manner.
>>
>> Given a host PID, I can read the 'tasks' file for the container's cgroup
>> to verify that the PID is associated with the container in question. Then
>> I can kill the PID with a signal. There is a small race condition in there,
>> where the PID could die & a new process could be born using the original
>> PID. Now this might not be very likely but I was thinking that if it is
>> possible to map from a host PID to a container PID, you can do it more
>> safely. eg Lookup the container PID associted with the host PID, then
>> setns() into the container and kill the container PID. Now although there
>> is still a race condition, you are guaranteed that if the race hits you'll
>> only kill a process within the same container, not the host at large,
>> which is good when the user invoking the API is unprivileged.
>
> I'm afraid I don't know of any way to do that. At some point a new
> /proc/self/pids or somesuch file was suggested to get that info.
I do wonder how the checkpoint/restart folks are getting that
information.
If you have the appropriate privileges you can use a unix domain socket.
Eric
next prev parent reply other threads:[~2012-11-27 13:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 10:15 Mapping between host & container PIDs ? Daniel P. Berrange
[not found] ` <20121127101555.GE24370-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-27 13:36 ` Serge Hallyn
2012-11-27 13:47 ` Daniel P. Berrange
[not found] ` <20121127134759.GL24370-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-27 21:49 ` Eric W. Biederman
2012-11-27 13:50 ` Eric W. Biederman [this message]
[not found] ` <87vccrm9xw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-30 0:43 ` Matt Helsley
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=87vccrm9xw.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox