linux-kernel - Re: [PATCH 2/2] pidns: Support unsharing the pid namespace.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110215190118.GA16707@redhat.com>
Date:	Tue, 15 Feb 2011 20:01:18 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Daniel Lezcano <daniel.lezcano@...e.fr>
Cc:	akpm@...ux-foundation.org, containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, xemul@...nvz.org, sukadev@...ibm.com,
	ebiederm@...ssion.com
Subject: Re: [PATCH 2/2] pidns: Support unsharing the pid namespace.

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 ?

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

	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.

Or not?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/