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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgNAkgqE7owqsmD+9-9fZtzMQ76H53a+Aat0CH670jNTUfbFA@mail.gmail.com>
Date:	Tue, 5 Mar 2013 09:37:05 +0100
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.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

On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> "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.

So, in summary, the point is that CLONE_VM is being used as a proxy
for CLONE_THREAD because the former is easier to test for, and
CLONE_THREAD requires CLONE_VM, right?

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
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/