clone(2) man page CLONE_NEWPID and CLONE_PARENT can be specified at the same time, also CLONE_NEWUSER and CLONE_PARENT

clone(2) man page CLONE_NEWPID and CLONE_PARENT can be specified at the same time, also CLONE_NEWUSER and CLONE_PARENT

[hoodit dev]

Hi

In clone(2) man page ERRORS section said EINVAL occur when set
CLONE_NEWPID and one (or both) of CLONE_THREAD or CLONE_PARENT were
specified in the flags mask
but in my test code, it can be specified CLONE_NEWPID and CLONE_PARENT
at the same time and works well (not in CLONE_THREAD)
In DESCRIPTION > the flags mask > CLONE_NEWPID, it says that it can't
be used with CLONE_THREAD only
So, I search linux github to find really CLONE_PARENT can't be used
with CLONE_NEWPID but there is no logic like that
(but I found CLONE_THREAD can't be used with CLONE_NEWUSER,
https://github.com/torvalds/linux/blob/219d54332a09e8d8741c1e1982f5eae56099de85/kernel/fork.c#L1815)

Similarly, in CLONE_NEWUSER, it says that "This flag can't be
specified in conjunction with CLONE_THREAD or CLONE_PARENT." but it
works on my test code with CLONE_PARENT
Also, in ERROR section only mentioned when CLONE_NEWUSER used with CLONE_THREAD

I think CLONE_NEWPID and CLONE_NEWUSER can't be used with CLONE_THREAD only.
If you think my opinion is reasonable, please let me know. I'll make a patch

Re: clone(2) man page CLONE_NEWPID and CLONE_PARENT can be specified at the same time, also CLONE_NEWUSER and CLONE_PARENT

[Carlos O'Donell]

On 4/15/25 7:34 AM, hoodit dev wrote:
> In clone(2) man page ERRORS section said EINVAL occur when set
> CLONE_NEWPID and one (or both) of CLONE_THREAD or CLONE_PARENT were
> specified in the flags mask
> but in my test code, it can be specified CLONE_NEWPID and CLONE_PARENT
> at the same time and works well (not in CLONE_THREAD)

The use of CLONE_NEWPID and CLONE_PARENT both creates a new PID namespace
and roots the created process at the parent of the caller.

This doesn't violate any of the rules around having only one process as
the root of the namespace.

The restriction of CLONE_PARENT is relevant to the root of the process tree.

I agree with your analysis that you should be able to use CLONE_NEWPID and
CLONE_PARENT. The outcome is that this creates a new process, whose root is
your parent, and who starts the new namespace as pid 1 (init) for that new
namespace.

> In DESCRIPTION > the flags mask > CLONE_NEWPID, it says that it can't
> be used with CLONE_THREAD only

This is correct.

> So, I search linux github to find really CLONE_PARENT can't be used
> with CLONE_NEWPID but there is no logic like that
> (but I found CLONE_THREAD can't be used with CLONE_NEWUSER,
> https://github.com/torvalds/linux/blob/219d54332a09e8d8741c1e1982f5eae56099de85/kernel/fork.c#L1815)

It does not make logical sense for CLONE_NEWPID to be used wtih CLONE_THREAD.

A new thread shares the same address space, and so should logically share
the same PID namespace. PID namespaces are created by cloning or unsharing
a given process that acts as root of the namespace.

Having a single process with a mixed PID namespace would break several
userspace invariants expected by C library implementations.

I expect the kernel to maintain this invariant.
  
> Similarly, in CLONE_NEWUSER, it says that "This flag can't be
> specified in conjunction with CLONE_THREAD or CLONE_PARENT." but it
> works on my test code with CLONE_PARENT
> Also, in ERROR section only mentioned when CLONE_NEWUSER used with CLONE_THREAD

Just because it works, which might be a bug, doesn't mean that we should
document that it works.

My position is similar here, a new USER namespace that is mixed within a
process that contains multiple threads violates a number of invariants.

The transition to a new user namespace should really start with a process
and all threads should share the same user namespace so ids can be stored
in thread-local objects and shared.
  
> I think CLONE_NEWPID and CLONE_NEWUSER can't be used with CLONE_THREAD only.
> If you think my opinion is reasonable, please let me know. I'll make a patch
  
I agree with this statement, CLONE_NEWPID and CLONE_NEWUSER should not be
usable with CLONE_THREAD.

-- 
Cheers,
Carlos.

Cc: clone(2) man page CLONE_NEWPID and CLONE_PARENT can be specified at the same time, also CLONE_NEWUSER and CLONE_PARENT

[hoodit dev]

I missed cc’ing earlier. Here’s a summary of what’s been discussed.


From: hoodit dev
To: Carlos O'Donell

Thanks for your explanation, I learn some insight

I understand this reply that CLONE_PARENT and CLONE_NEWUSER can be
used together but I get little confusion about this

> >Similarly, in CLONE_NEWUSER, it says that "This flag can't be
> >specified in conjunction with CLONE_THREAD or CLONE_PARENT." but it
> >works on my test code with CLONE_PARENT
> >Also, in ERROR section only mentioned when CLONE_NEWUSER used with CLONE_THREAD

>Just because it works, which might be a bug, doesn't mean that we should
>document that it works.

These 2 lines confused me. I mean, the description section and the
error section seem to have different content, and I tested it.


My statement
CLONE_NEWPID + CLONE_PARENT          ok
CLONE_NEWPID + CLONE_THREAD         no
CLONE_NEWUSER + CLONE_PARENT      ok
CLONE_NEWUSER + CLONE_THREAD     no


--------

From: Carlos O'Donell
To: hoodit dev

On 4/15/25 9:27 AM, hoodit dev wrote:
> My statement
> CLONE_NEWPID + CLONE_PARENT          ok
> CLONE_NEWPID + CLONE_THREAD         no
> CLONE_NEWUSER + CLONE_PARENT      ok
> CLONE_NEWUSER + CLONE_THREAD     no

Thank you.

I see what you were trying to describe.

I agree that the permutations you descirbe as "OK" make sense.

I also agree that CLONE_NEWUSER should be possible to use with CLONE_PARENT
because it doesn't violate any constraints, it simply declares the current
callers parent as the parent of the newly created task.

I agree that the man page for clone.2 should get changed to either explain
why CLONE_NEWUSER + CLONE_PARENT can't be used, or remove the restriction.

-- 
Cheers,
Carlos.


--------

From: hoodit dev
To: Carlos O'Donell

Thank you for your help
I was quite confused because this was my first time in this situation,
but the kind explanation helped me a lot.

I will check man page and I'm gonna trying to patch it
The revision direction is same as I mentioned

> CLONE_NEWPID + CLONE_PARENT          ok
> CLONE_NEWPID + CLONE_THREAD         no
> CLONE_NEWUSER + CLONE_PARENT      ok
> CLONE_NEWUSER + CLONE_THREAD     no

Also,

> I agree that the man page for clone.2 should get changed to either explain
> why CLONE_NEWUSER + CLONE_PARENT can't be used, or remove the restriction.

I will remove restriction CLONE_NEWUSER + CLONE_PARENT (I still have
confusion about why you mention "either explain why CLONE_NEWUSER +
CLONE_PARENT can't be used, or remove the restriction.", is it ok to
just remove restriction only? because CLONE_NEWUSER + CLONE_PARENT can
be used so I can't explain why CLONE_NEWUSER + CLONE_PARENT can't be
used)


--------

From: Carlos O'Donell
To: hoodit dev

On 4/15/25 10:41 AM, hoodit dev wrote:
>> I agree that the man page for clone.2 should get changed to either explain
>> why CLONE_NEWUSER + CLONE_PARENT can't be used, or remove the restriction.
>
> I will remove restriction CLONE_NEWUSER + CLONE_PARENT (I still have
> confusion about why you mention "either explain why CLONE_NEWUSER +
> CLONE_PARENT can't be used, or remove the restriction.", is it ok to
> just remove restriction only? because CLONE_NEWUSER + CLONE_PARENT can
> be used so I can't explain why CLONE_NEWUSER + CLONE_PARENT can't be
> used)

Removing the restriction is an acceptable path forward in my opinion
and it makes sense from first principles.

The question here is if there are any CLONE_NEWUSER interactions with
CLONE_PARENT that we are unaware of that need to be accounted for.

To discover those we would need to ask upstream and gather broader
consensus.


--------

From: hoodit dev
To: Carlos O'Donell

Thank you for your precise content arrangement.

As far as I checked, it has nothing to do with the flag part in the
code, but it is not accurate. Therefore, I think this part needs to be
checked.

> To discover those we would need to ask upstream and gather broader
> consensus.

How should I handle this?

Also, I wasn't referring to these email replies in Alejandro Colomar
and linux-man@vger.kernel.org , how can I solve this?

Re: Cc: clone(2) man page CLONE_NEWPID and CLONE_PARENT can be specified at the same time, also CLONE_NEWUSER and CLONE_PARENT

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]

Hi Hoodit, Carlos,

On Sun, Apr 20, 2025 at 04:54:20AM +0900, hoodit dev wrote:
> I missed cc’ing earlier. Here’s a summary of what’s been discussed.

Thanks!

[...]

> --------
> 
> From: hoodit dev
> To: Carlos O'Donell
> 
> Thank you for your precise content arrangement.
> 
> As far as I checked, it has nothing to do with the flag part in the
> code, but it is not accurate. Therefore, I think this part needs to be
> checked.
> 
> > To discover those we would need to ask upstream and gather broader
> > consensus.
> 
> How should I handle this?

If you (Hoodit and Carlos) have agreed to at least part of a
documentation change, you can send a patch, CCing me, the list, and
Carlos.

For the part that you need more consensus, I guess you'd need to find
out who the maintainers of the kernel system call are, and CC them.

The clone(2) system call is defined here:

	alx@debian:~/src/linux/linux/master$ find -type f \
		| grep '\.c$' \
		| xargs grepc -l -tfld clone;
	./kernel/fork.c

And while that doesn't seem to appear in the MAINTAINERS file, from the
git-log(1), I think you want to talk to at least Andrew Morton and the
<linux-kernel@vger.kernel.org> mailing list.

alx@debian:~/src/linux/linux/master$ git log --pretty=fuller -- kernel/fork.c \
	| grep -e Commit: -e Signed-off-by: \
	| head -n100 \
	| sort \
	| uniq -c \
	| sort \
	| tac \
	| head -n10;
     13 Commit:     Linus Torvalds <torvalds@linux-foundation.org>
     12 Commit:     Andrew Morton <akpm@linux-foundation.org>
     12     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
     10 Commit:     Christian Brauner <brauner@kernel.org>
     10     Signed-off-by: Christian Brauner <brauner@kernel.org>
      6     Signed-off-by: Oleg Nesterov <oleg@redhat.com>
      2 Commit:     Kent Overstreet <kent.overstreet@linux.dev>
      2     Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
      2     Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
      2     Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Since this is about APIs, also CC <linux-api@vger.kernel.org>.  Of
course, please keep Carlos, me, and <linux-man@vger.kernel.org> in CC
too.

> Also, I wasn't referring to these email replies in Alejandro Colomar
> and linux-man@vger.kernel.org , how can I solve this?

Carlos (or Hoodit), if you are comfortable with mutt(1)/neomutt(1), you
could do the following:

	-  Edit your local copy of the email to add the linux-man@ list
	   in a To: header field.  (Otherwise, the list will ignore the
	   mail received in the following step.)

	-  Bounce the mail to both me and the list.

Or you can just do nothing; we got here a resume of what you talked, so
I guess that's okay.  Just remember to CC the list next time.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]