linux-kernel - Re: [PATCH] allow a task to join a 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 5 Jun 2012 15:33:34 +0400
From:	Glauber Costa <glommer@...allels.com>
To:	Daniel Lezcano <daniel.lezcano@...e.fr>
CC:	<linux-kernel@...r.kernel.org>, <cgroups@...r.kernel.org>,
	<devel@...nvz.org>, <kir@...allels.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] allow a task to join a pid namespace

On 06/05/2012 01:36 PM, Daniel Lezcano wrote:
> On 06/04/2012 03:33 PM, Glauber Costa wrote:
>> Currently, it is possible for a process  to join existing
>> net, uts and ipc namespaces. This patch allows a process to join an
>> existing pid namespace as well.
>>
>> For that to remain sane, some restrictions are made in the calling process:
>>
>> * It needs to be in the parent namespace of the namespace it wants to jump to
>> * It needs to sit in its own session and group as a leader.
>>
>> The rationale for that, is that people want to trigger actions in a Container
>> from the outside. For instance, mainstream linux recently gained the ability
>> to safely reboot a container. It would be desirable, however, that this
>> action is triggered from an admin in the outside world, very much like a
>> power switch in a physical box.
>>
>> This would also allow us to connect a console to the container, provide a
>> repair mode for setups without networking (or with a broken one), etc.
>
> Hi Glauber,
>
> I am in favor of this patch but I think the pidns support won't be
> complete and some corner-cases are not handled.
>
> May be you can look at Eric's patchset [1] where, IMO, everything is
> taken into account. Some of the patches may be already upstream.
>
> Thanks
>    -- Daniel
>

Daniel,

Please let me know what you think of the attached patch. It is ontop of 
Eric's tree that you pointed me to, but I am not really using any of its 
functionality, so this would be equally doable in current mainline 
kernel - but I wanted to make sure it integrates well with what Eric is 
doing as well.

It is a bit wasteful space-wise, but this approach pretty much 
guarantees we don't need to update pointers anywhere - therefore, 
totally lock-free. pid->level is only updated after 
switch_task_namespaces(), so every call before that will see correct 
information up to the previous level.



View attachment "0001-pid_ns-expand-the-current-pid-namespace-to-a-new-nam.patch" of type "text/x-patch" (5576 bytes)