From: Oren Laadan <orenl@cs•columbia.edu>
To: Daniel Lezcano <daniel.lezcano@free•fr>
Cc: "Eric W. Biederman" <ebiederm@xmission•com>,
Pavel Emelyanov <xemul@parallels•com>,
Linux Netdev List <netdev@vger•kernel.org>,
containers@lists•linux-foundation.org,
Netfilter Development Mailinglist
<netfilter-devel@vger•kernel.org>,
Ben Greear <greearb@candelatech•com>
Subject: Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
Date: Wed, 03 Mar 2010 15:59:05 -0500 [thread overview]
Message-ID: <4B8ECD99.3040107@cs.columbia.edu> (raw)
In-Reply-To: <4B8AE8C1.1030305@free.fr>
Daniel Lezcano wrote:
> Eric W. Biederman wrote:
>> Pavel Emelyanov <xemul@parallels•com> writes:
>>
>>> Eric W. Biederman wrote:
>>>> Pavel Emelyanov <xemul@parallels•com> writes:
>>>>
>>>>> Eric W. Biederman wrote:
>>>>>> Pavel Emelyanov <xemul@parallels•com> writes:
>>>>>>
>>>>>>> Thanks. What's the problem with setns?
>>>>>> joining a preexisting namespace is roughly the same problem as
>>>>>> unsharing a namespace. We simply haven't figure out how to do it
>>>>>> safely for the pid and the uid namespaces.
>>>>> The pid may change after this for sure. What problems do you know
>>>>> about it? What if we try to allocate the same PID in a new space
>>>>> or return -EBUSY? This will be a good starting point. If we manage
>>>>> to fix it later this will not break the API at all.
>>>> Parentage. The pid is the identity of a process and all kinds of things
>>>> make assumptions in all kinds of strange places. I don't see how
>>>> waitpid can work if you change the pid.
>>> Agree. But what if we enter a pid space, which is a subnamespace of a current
>>> one? In that case parent will still see the task by its old pid. We can restrict
>>> first version of entering with this rule as well and this restriction will not
>>> block us in typical usecase (I mean enter a container from a host).
>> When I was thinking about pid namespaces and unshare last time. The idea I came
>> to was we unshare of the pid namespace should only affect which pid namespace
>> your children are in.
>>
>> I remember that do that there were a few cases where you would have to access
>> task->pid->pid_ns instead of task->nsproxy->pid_ns, but essentially it was pretty
>> simple.
>>
>>>> glibc doesn't cope if you change someones pid.
>>> OK, but what if we try to allocate the same pid returning -EBUSY on failure?
>>>
>>> My aim is to provide even a restricted enter. For most of the cases this
>>> should work and make our lives easier. So two restrictions currently:
>>> a) enter a sub namespace
>>> b) allocate the same pid as we have now
>>>
>>> Hm? :)
>> Replacing struct pid is guaranteed to do all kinds of nasty things with
>> signal handling and the like, de_thread is nasty enough and you are talking
>> something worse. So if we can change pid namespaces without changing
>> the pid I am for it.
>
> I agree with all the points you and Pavel you talked about but I don't
> feel comfortable to have the current process to switch the pid namespace
> because of the process tree hierarchy (what will be the parent of the
> process when you enter the pid namespace for example). What is the
> difference with the sys_bindns or the sys_hijack, proposed a couple of
> years ago ?
>
> I did a suggestion some weeks ago about a new syscall 'cloneat' where
> the child process becomes the child of the targeted process specified in
> the syscall. Maybe it would be interesting to replace the 'setns' by, or
> add, a 'cloneat' syscall with the file descriptor passed as parameter.
> The copy_process function shall not use the nsproxy of the caller but
> the one provided in the fd argument.
>
> The newly created process becomes the child of the process where we
> retrieve the namespace with nsfd and this one have to 'waitpid' it, (the
> caller of 'cloneat' can not wait it). It's a bit similar with the
> CLONE_PARENT flag, except the creation order is inverted (the father
> creates for the child).
>
> So when entering the container, we specify the pid 1 of the container
> which is usually a child reaper.
>
> Does it make sense ?
For what it's worth, I think that this suggestion (cloneat) is the
so far the cleanest to allow a process to enter an existing namespace.
Oren.
next prev parent reply other threads:[~2010-03-03 20:59 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 14:05 RFC: netfilter: nf_conntrack: add support for "conntrack zones" Patrick McHardy
2010-01-14 15:05 ` jamal
2010-01-14 15:37 ` Patrick McHardy
2010-01-14 17:33 ` jamal
2010-01-15 10:15 ` Patrick McHardy
2010-01-15 15:19 ` jamal
2010-02-22 20:46 ` Eric W. Biederman
2010-02-22 21:55 ` jamal
2010-02-22 23:17 ` Eric W. Biederman
[not found] ` <m1wry46es9.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-02-23 13:27 ` jamal
2010-02-23 14:07 ` Eric W. Biederman
2010-02-23 14:20 ` jamal
2010-02-23 20:00 ` Eric W. Biederman
2010-02-23 23:09 ` jamal
2010-02-24 1:43 ` Eric W. Biederman
2010-02-25 20:57 ` [RFC][PATCH] ns: Syscalls for better namespace sharing control Eric W. Biederman
2010-02-25 21:31 ` Daniel Lezcano
2010-02-25 21:49 ` Eric W. Biederman
2010-02-25 22:13 ` Daniel Lezcano
2010-02-25 22:31 ` Eric W. Biederman
2010-02-26 20:35 ` Eric W. Biederman
2010-02-25 21:46 ` Matt Helsley
2010-02-25 21:54 ` Eric W. Biederman
2010-02-26 0:53 ` Eric W. Biederman
2010-02-26 1:09 ` Matt Helsley
2010-02-26 1:26 ` Eric W. Biederman
2010-02-26 3:15 ` [RFC][PATCH] ns: Syscalls for better namespace sharing control. v2 Eric W. Biederman
[not found] ` <m18wagy9f3.fsf_-_-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-03-03 20:29 ` Jonathan Corbet
2010-03-03 20:50 ` Eric W. Biederman
[not found] ` <m1pr3t2fvl.fsf_-_-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-02-26 21:13 ` [RFC][PATCH] ns: Syscalls for better namespace sharing control Pavel Emelyanov
2010-02-26 21:24 ` Eric W. Biederman
2010-02-26 21:34 ` Pavel Emelyanov
2010-02-26 21:42 ` Eric W. Biederman
2010-02-26 21:58 ` Oren Laadan
2010-02-26 22:16 ` Eric W. Biederman
2010-02-26 22:52 ` Oren Laadan
2010-02-26 23:13 ` Eric W. Biederman
2010-02-27 8:30 ` Pavel Emelyanov
2010-02-27 9:04 ` Eric W. Biederman
[not found] ` <m1mxyvrqvk.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-02-27 9:21 ` Pavel Emelyanov
2010-02-27 9:42 ` Eric W. Biederman
2010-02-27 16:16 ` Pavel Emelyanov
2010-02-27 19:08 ` Eric W. Biederman
2010-02-27 19:29 ` Pavel Emelyanov
2010-02-27 19:44 ` Eric W. Biederman
2010-02-28 22:05 ` Daniel Lezcano
2010-03-01 19:24 ` Eric W. Biederman
2010-03-01 21:42 ` Eric W. Biederman
2010-03-02 13:10 ` Cedric Le Goater
2010-03-02 15:03 ` Pavel Emelyanov
2010-03-02 15:14 ` Jan Engelhardt
2010-03-02 21:45 ` Eric W. Biederman
2010-03-02 21:19 ` Sukadev Bhattiprolu
2010-03-02 22:13 ` Eric W. Biederman
2010-03-03 0:07 ` Sukadev Bhattiprolu
2010-03-03 0:46 ` Eric W. Biederman
2010-03-03 15:38 ` Serge E. Hallyn
2010-03-03 19:47 ` Eric W. Biederman
2010-03-04 21:45 ` Eric W. Biederman
2010-03-04 22:55 ` Jan Engelhardt
2010-03-03 16:50 ` Pavel Emelyanov
2010-03-03 20:16 ` Eric W. Biederman
2010-03-05 19:18 ` Pavel Emelyanov
2010-03-05 20:26 ` Eric W. Biederman
2010-03-06 14:47 ` Daniel Lezcano
[not found] ` <4B926B1B.5070207-GANU6spQydw@public.gmane.org>
2010-03-06 20:48 ` Eric W. Biederman
[not found] ` <m1aaulyy5c.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-03-06 21:26 ` Daniel Lezcano
2010-03-08 8:32 ` Eric W. Biederman
2010-03-08 16:54 ` Daniel Lezcano
2010-03-08 17:29 ` Eric W. Biederman
2010-03-08 19:57 ` Daniel Lezcano
2010-03-08 20:24 ` Eric W. Biederman
2010-03-08 20:42 ` Daniel Lezcano
2010-03-08 20:47 ` Eric W. Biederman
2010-03-08 21:12 ` Daniel Lezcano
2010-03-08 21:25 ` Eric W. Biederman
2010-03-08 21:49 ` Serge E. Hallyn
2010-03-08 22:24 ` Eric W. Biederman
2010-03-09 10:03 ` Daniel Lezcano
2010-03-09 10:13 ` Eric W. Biederman
2010-03-09 10:26 ` Daniel Lezcano
2010-03-10 21:16 ` Daniel Lezcano
2010-03-08 17:07 ` Serge E. Hallyn
2010-03-08 17:35 ` Eric W. Biederman
2010-03-08 17:47 ` Serge E. Hallyn
2010-03-03 20:59 ` Oren Laadan [this message]
2010-03-03 21:05 ` Eric W. Biederman
[not found] ` <m1bpfbwuze.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-02-26 21:35 ` Pavel Emelyanov
2010-02-26 21:49 ` Eric W. Biederman
2010-02-23 23:49 ` RFC: netfilter: nf_conntrack: add support for "conntrack zones" Matt Helsley
2010-02-24 1:32 ` Eric W. Biederman
2010-02-24 1:39 ` Serge E. Hallyn
2010-01-14 18:32 ` Ben Greear
2010-01-15 15:03 ` jamal
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=4B8ECD99.3040107@cs.columbia.edu \
--to=orenl@cs$(echo .)columbia.edu \
--cc=containers@lists$(echo .)linux-foundation.org \
--cc=daniel.lezcano@free$(echo .)fr \
--cc=ebiederm@xmission$(echo .)com \
--cc=greearb@candelatech$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=netfilter-devel@vger$(echo .)kernel.org \
--cc=xemul@parallels$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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