[Devel] Re: [PATCH 6/6] pidns: Support unsharing the pid namespace.
Oleg Nesterov
oleg at redhat.com
Sun Jun 20 13:14:54 PDT 2010
On 06/20, Eric W. Biederman wrote:
>
> Unsharing of the pid namespace unlike unsharing of other namespaces
> does not take affect immediately. Instead it affects the children
> created with fork and clone.
Cough. It is too late to me to even try to understand the changelog.
Instead I tried to quickly read the patch. Most probably I missed
somthing, but still I'd like to ask the quiestion.
So. If I understand correctly, the patch is simple:
- unshare(CLONE_NEWPID) changes current->proxy->pid_ns,
but do not change current->pids[] and thus it doesn't
change task_active_pid_ns().
- since copy_process() uses ->proxy->pid_ns for alloc_pid()
the new children will fall into the new ns.
IOW, the caller becomes the "swapper" for the new namespace.
Correct?
If yes, I'm afraid nobody except you will understand this magic ;)
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 ?
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.
I hope I missed something, this all is too subtle for me. And I
still do not understand 4/6 which adds ns->dead.
Oleg.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list