From: ebiederm@xmission•com (Eric W. Biederman)
To: "Serge E. Hallyn" <serue@us•ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux•vnet.ibm.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: Thu, 04 Mar 2010 13:45:23 -0800 [thread overview]
Message-ID: <m1pr3j92x8.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <m13a0hmblr.fsf@fess.ebiederm.org> (Eric W. Biederman's message of "Wed\, 03 Mar 2010 11\:47\:12 -0800")
ebiederm@xmission•com (Eric W. Biederman) writes:
> "Serge E. Hallyn" <serue@us•ibm.com> writes:
>
>> Quoting Eric W. Biederman (ebiederm@xmission•com):
>>> Sukadev Bhattiprolu <sukadev@linux•vnet.ibm.com> writes:
>>>
>>> > Eric W. Biederman [ebiederm@xmission•com] wrote:
>>> > |
>>> > | I think replacing a struct pid for another struct pid allocated in
>>> > | descendant pid_namespace (but has all of the same struct upid values
>>> > | as the first struct pid) is a disastrous idea. It destroys the
>>> >
>>> > True. Sorry, I did not mean we would need a new 'struct pid' for an
>>> > existing process. I think we talked earlier of finding a way of attaching
>>> > additional pid numbers to the same struct pid.
>>>
>>> I just played with this and if you make the semantics of unshare(CLONE_NEWPID)
>>> to be that you become the idle task aka pid 0, and not the init task pid 1 the
>>> implementation is trivial.
>>
>> Heh, and then (browsing through your copy_process() patch hunks) the next
>> forked task becomes the child reaper for the new pidns? <shrug> why not
>> I guess.
>>
>> Now if that child reaper then gets killed, will the idle task get killed too?
>
> No.
>
>> And if not, then idle task can just re-populating the new pidns with new
>> idle tasks...
>
> After zap_pid_namespace interesting...
>
>> If this brought us a step closer to entering an existing pidns that would
>> be one thing, but is there actually any advantage to being able to
>> unshare a new pidns? Oh, I guess there is - PAM can then use it at
>> login, which might be neat.
>
> I have to say that the semantics of my patch are unworkable for
> unshare. Unless I am mistaken for PAM to use it requires that the
> current process fully change and become what it needs to be.
> Requiring an extra fork to fully complete the process is a problem.
>
> Scratch one bright idea.
Maybe not. I just looked and in the vast majority of cases the login
process goes like this.
{
setup stuff include pam
child = fork();
if (!child) {
setuid()
exec /bin/bash
}
waitpid(child);
pam and other cleanup
}
So an unshare of the pid namespace that doesn't really take effect
until we fork may actually be usable from pam, and in fact is probably
the preferred implementation. It looks like neither openssh nor login
from util-linux-ng will cope properly with getting any pid back from
wait() except the pid of their child. It looks like they both with
terminate. Which means if you login in a new pid namespace (where the
unsharing process becomes pid 1) and call nohup everything will get
killed and you will be logged out.
Eric
next prev parent reply other threads:[~2010-03-04 21:45 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 [this message]
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
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=m1pr3j92x8.fsf@fess.ebiederm.org \
--to=ebiederm@xmission$(echo .)com \
--cc=containers@lists$(echo .)linux-foundation.org \
--cc=greearb@candelatech$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=netfilter-devel@vger$(echo .)kernel.org \
--cc=serue@us$(echo .)ibm.com \
--cc=sukadev@linux$(echo .)vnet.ibm.com \
--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