From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
To: "Serge Hallyn" <serge.hallyn@ubuntu.com>,
"Stéphane Graber" <stgraber@ubuntu.com>
Cc: linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH RFC] pidns: introduce syscall getvpid
Date: Wed, 16 Sep 2015 10:37:33 +0300 [thread overview]
Message-ID: <55F91C3D.1040209@yandex-team.ru> (raw)
In-Reply-To: <20150915174143.GE4699@ubuntumail>
On 15.09.2015 20:41, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgraber@ubuntu.com):
>> On Tue, Sep 15, 2015 at 06:01:38PM +0300, Konstantin Khlebnikov wrote:
>>> On 15.09.2015 17:27, Eric W. Biederman wrote:
>>>> Konstantin Khlebnikov <khlebnikov@yandex-team.ru> writes:
>>>>
>>>>> pid_t getvpid(pid_t pid, pid_t source, pid_t target);
>>>>>
>>>>> This syscall converts pid from one pid-ns into pid in another pid-ns:
>>>>> it takes @pid in namespace of @source task (zero for current) and
>>>>> returns related pid in namespace of @target task (zero for current too).
>>>>> If pid is unreachable from target pid-ns then it returns zero.
>>>>
>>>> This interface as presented is inherently racy. It would be better
>>>> if source and target were file descriptors referring to the namespaces
>>>> you wish to translate between.
>>>
>>> Yep, it's racy. As well as any operation with non-child pids.
>>> With file descriptors for source/target result will be racy anyway.
>>>
>>>>
>>>>> Such conversion is required for interaction between processes from
>>>>> different pid-namespaces. For example when system service talks with
>>>>> client from isolated container via socket about task in container:
>>>>
>>>> Sockets are already supported. At least the metadata of sockets is.
>>>>
>>>> Maybe we need this but I am not convinced of it's utility.
>>>>
>>>> What are you trying to do that motivates this?
>>>
>>> I'm working on hierarchical container management system which
>>> allows to create and control nested sub-containers from containers
>>> ( https://github.com/yandex/porto ). Main server works in host and
>>> have to interact with all levels of nested namespaces. This syscall
>>> makes some operations much easier: server must remember only pid in
>>> host pid namespace and convert it into right vpid on demand.
>>
>> Note that as Eric said earlier, sending a PID inside a ucred through a
>> unix socket will have the pid translated.
>>
>> So while your solution certainly should be faster, you can already achieve
>> what you want today by doing:
>>
>> == Translate PID in container to PID in host
>> - open a socket
>> - setns to container's pidns
>> - send ucred from that container containing the requested container PID
>> - host sees the host PID
>>
>> == Translate PID on host to PID in container
>> - open a socket
>> - setns to container's pidns
>> - send ucred from the host containing the request host PID
>> (send will fail if the host PID isn't part of that container)
>> - container sees the container PID
>
> In addition, since commit e4bc332451 : /proc/PID/status: show all sets of pid according to ns
> we now also have 'NSpid' etc in /proc/$$/status.
>
As I see this works perfectly only for converting host pid into virtual.
Backward conversion is troublesome: we have to scan all pids in host
procfs and somehow filter tasks from container and its sub-pid-ns.
Or I am missing something trivial?
--
Konstantin
next prev parent reply other threads:[~2015-09-16 7:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 12:09 Konstantin Khlebnikov
2015-09-15 14:20 ` Oleg Nesterov
2015-09-15 14:27 ` Eric W. Biederman
2015-09-15 15:01 ` Konstantin Khlebnikov
2015-09-15 15:17 ` Stéphane Graber
2015-09-15 15:51 ` Konstantin Khlebnikov
2015-09-15 17:41 ` Serge Hallyn
2015-09-16 7:37 ` Konstantin Khlebnikov [this message]
2015-09-16 14:39 ` Serge E. Hallyn
2015-09-16 14:49 ` Eric W. Biederman
2015-09-16 16:31 ` Serge E. Hallyn
2015-09-21 2:49 ` Chen Fan
2015-09-21 14:22 ` Serge E. Hallyn
2015-09-22 7:42 ` Konstantin Khlebnikov
2015-09-22 21:00 ` Eric W. Biederman
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=55F91C3D.1040209@yandex-team.ru \
--to=khlebnikov@yandex-team.ru \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=serge.hallyn@ubuntu.com \
--cc=stgraber@ubuntu.com \
--cc=torvalds@linux-foundation.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
Powered by JetHome