linux-kernel - Re: For review: pid_namespaces(7) man page

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-next>] [day] [month] [year] [list]

Message-ID: <87r4jucprp.fsf@xmission.com>
Date:	Mon, 04 Mar 2013 22:41:14 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	mtk.manpages@...il.com
Cc:	Rob Landley <rob@...dley.net>,
	linux-man <linux-man@...r.kernel.org>,
	Linux Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: For review: pid_namespaces(7) man page

"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:

> Eric,
>
> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
>>
>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@...dley.net>
> wrote:
>>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote:
> [...]
>>>>>>> Because the above unshare(2) and setns(2) calls only change the
>>>>>>> PID namespace for created children, the clone(2) calls neces‐
>>>>>>> sarily put the new thread in a different PID namespace from the
>>>>>>> calling thread.
>>>>>>
>>>>>>
>>>>>> Um, no they don't. They fail. That's the point.
>>>>>
>>>>> (Good catch.)
>>>>>
>>>>>> They _would_ put the new
>>>>>> thread in a different PID namespace, which breaks the definition
> of threads.
>>>>>>
>>>>>> How about:
>>>>>>
>>>>>> The above unshare(2) and setns(2) calls change the PID namespace
> of
>>>>>> children created by subsequent clone(2) calls, which is
> incompatible
>>>>>> with CLONE_VM.
>>>>>
>>>>> I decided on:
>>>>>
>>>>> The point here is that unshare(2) and setns(2) change the PID
>>>>> namespace for created children but not for the calling process,
>>>>> while clone(2) CLONE_VM specifies the creation of a new thread
>>>>> in the same process.
>>>>
>>>> Can we make that "for all new tasks created" instead of "created
>>>> children"
>>>>
>>>> Othewise someone might expect CLONE_THREAD would work as you
>>>> CLONE_THREAD creates a thread and not a child...
>>>
>>> The term "task" is kernel-space talk that rarely appears in man
> pages,
>>> so I am reluctant to use it.
>>
>> With respect to clone and in this case I am not certain we can
> properly
>> describe what happens without talking about tasks. But it is worth
>> a try.
>>
>>
>>> How about this:
>>>
>>> The point here is that unshare(2) and setns(2) change the PID
>>> namespace for processes subsequently created by the caller, but
>>> not for the calling process, while clone(2) CLONE_VM specifies
>>> the creation of a new thread in the same process.
>>
>> Hmm. How about this.
>>
>> The point here is that unshare(2) and setns(2) change the PID
>> namespace that will be used by in all subsequent calls to clone
>> and fork by the caller, but not for the calling process, and
>> that all threads in a process must share the same PID
>> namespace. Which makes a subsequent clone(2) CLONE_VM
>> specify the creation of a new thread in the a different PID
>> namespace but in the same process which is impossible.
>
> I did a little tidying:
>
> The point here is that unshare(2) and setns(2) change the
> PID namespace that will be used in all subsequent calls
> to clone(2) and fork(2), but do not change the PID names‐
> pace of the calling process. Because a subsequent
> clone(2) CLONE_VM would imply the creation of a new
> thread in a different PID namespace, the operation is not
> permitted.
>
> Okay?

That seems reasonable.

CLONE_THREAD might be better to talk about.  The check is CLONE_VM
because it is easier and CLONE_THREAD implies CLONE_THREAD.

> Having asked that, I realize that I'm still not quite comfortable with
> this text. I think the problem is really one of terminology. At the
> start of this passage in the page, there is the sentence:
>
> Every thread in a process must be in the 
> same PID namespace.
>
> Can you define "thread" in this context?

Most definitely a thread group created with CLONE_THREAD.  It is pretty
ugly in just the old fashioned CLONE_VM case too, but that might be
legal.

In a few cases I think the implementation overshoots and test for VM
sharing instead of thread group membership because VM sharing is easier
to test for, and we already have tests for that.

Eric

--
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/