All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@free.fr>
To: Oleg Nesterov <oleg@redhat.com>
Cc: akpm@linux-foundation.org, containers@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, xemul@openvz.org,
	sukadev@us.ibm.com, ebiederm@xmission.com
Subject: Re: [PATCH 2/2] pidns: Support unsharing the pid namespace.
Date: Thu, 17 Feb 2011 00:47:37 +0100	[thread overview]
Message-ID: <4D5C6219.8060207@free.fr> (raw)
In-Reply-To: <20110215190118.GA16707@redhat.com>

On 02/15/2011 08:01 PM, Oleg Nesterov wrote:
> On 02/15, Daniel Lezcano wrote:
>> - Pass both nsproxy->pid_ns and task_active_pid_ns to copy_pid_ns
>>    As they can now be different.
> But since they can be different we have to convert some users of
> current->nsproxy first? But that patch was dropped.
>
>> Unsharing of the pid namespace unlike unsharing of other namespaces
>> does not take effect immediately.  Instead it affects the children
>> created with fork and clone.
> IOW, unshare(CLONE_NEWPID) implicitly affects the subsequent fork(),
> using the very subtle way.
>
> I have to admit, I can't say I like this very much. OK, if we need
> this, can't we just put something into, say, signal->flags so that
> copy_process can check and create the new namespace.
>
> Also. I remember, I already saw something like this and google found
> my questions. I didn't actually read the new version, perhaps my
> concerns were already answered...
>
> 	But what if the task T does unshare(CLONE_NEWPID) and then, say,
> 	pthread_create() ? Unless I missed something, the new thread won't
> 	be able to see T ?

Right. Is it really a problem ? I mean it is a weird use case where we 
fall in a weird situation.
I suppose we can do the same weird combination with clone.
IMHO, the userspace is responsible of how it uses the syscalls. Until 
the system is safe, everything is ok, no ?

> 	and, in this case the exiting sub-namespace init also kills its
> 	parent?

I don't think so because the zap_pid_ns_processes does not hit the 
parent process when it browses the pidmap.

I tried the following program without problem:

#include <stdio.h>
#define _GNU_SOURCE
#include <sched.h>
#include <pthread.h>

void *routine(void *data)
{
         printf("pid %d!\n", getpid());
         return NULL;
}

int main(int argc, char *argv[])
{
         char **aux = &argv[1];
         pthread_t t;

         if (unshare(CLONE_NEWPID)) {
                 perror("unshare");
                 return -1;
         }

         if (pthread_create(&t, NULL, routine, NULL)) {
                 perror("pthread_create");
                 return -1;
         }

         if (pthread_join(t, NULL)) {
                 perror("pthread_join");
                 return -1;
         }

         printf("joined\n");

         return 0;
}

> 	OK, suppose it does fork() after unshare(), then another fork().
> 	In this case the second child lives in the same namespace with
> 	init created by the 1st fork, but it is not descendant ? This means
> 	in particular that if the new init exits, zap_pid_ns_processes()->
> 	do_wait() can't work.

Hmm, good question. IMO, we should prevent such case for now in the same 
way we added the flag 'dead', IOW adding a flag 'busy' for example.


  parent reply	other threads:[~2011-02-16 23:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-15 16:53 [PATCH 1/2] pidns: Don't allow new pids after the namespace is dead Daniel Lezcano
2011-02-15 16:53 ` [PATCH 2/2] pidns: Support unsharing the pid namespace Daniel Lezcano
     [not found]   ` <1297788824-20534-2-git-send-email-daniel.lezcano-GANU6spQydw@public.gmane.org>
2011-02-15 19:01     ` Oleg Nesterov
2011-02-24  1:12     ` Rob Landley
2011-02-15 19:01   ` Oleg Nesterov
2011-02-15 19:15     ` [PATCH 0/1] Was: " Oleg Nesterov
     [not found]       ` <20110215191521.GB16707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-02-15 19:17         ` [PATCH 1/1][3rd resend] sys_unshare: remove the dead CLONE_THREAD/SIGHAND/VM code Oleg Nesterov
2011-02-15 19:17       ` Oleg Nesterov
2011-02-21  0:17         ` Serge E. Hallyn
     [not found]         ` <20110215191711.GC16707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-02-21  0:17           ` Serge E. Hallyn
2011-02-16 23:47     ` Daniel Lezcano [this message]
     [not found]       ` <4D5C6219.8060207-GANU6spQydw@public.gmane.org>
2011-02-17 20:29         ` [PATCH 2/2] pidns: Support unsharing the pid namespace Oleg Nesterov
2011-02-17 20:29       ` Oleg Nesterov
     [not found]         ` <20110217202959.GA16076-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-02-17 22:35           ` Greg Kurz
2011-02-17 22:35         ` Greg Kurz
     [not found]           ` <4D5DA2CF.5010200-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2011-02-18 14:40             ` Oleg Nesterov
2011-02-18 14:40           ` Oleg Nesterov
     [not found]     ` <20110215190118.GA16707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-02-15 19:15       ` [PATCH 0/1] Was: " Oleg Nesterov
2011-02-16 23:47       ` [PATCH 2/2] " Daniel Lezcano
2011-02-24  1:12   ` Rob Landley
     [not found] ` <1297788824-20534-1-git-send-email-daniel.lezcano-GANU6spQydw@public.gmane.org>
2011-02-15 16:53   ` Daniel Lezcano
2011-02-15 18:30   ` [PATCH 1/2] pidns: Don't allow new pids after the namespace is dead Oleg Nesterov
2011-02-15 18:30 ` Oleg Nesterov
     [not found]   ` <20110215183028.GA15568-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2011-02-16 23:21     ` Daniel Lezcano
2011-02-16 23:21   ` Daniel Lezcano
2011-02-17 20:54     ` Oleg Nesterov
     [not found]     ` <4D5C5BE8.5020803-GANU6spQydw@public.gmane.org>
2011-02-17 20:54       ` Oleg Nesterov

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=4D5C6219.8060207@free.fr \
    --to=daniel.lezcano@free.fr \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=sukadev@us.ibm.com \
    --cc=xemul@openvz.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.