[Devel] Re: [RFC][PATCH 1/2] Deny CLONE_PARENT|CLONE_NEWPID combination

[Eric W. Biederman]

Sukadev Bhattiprolu <sukadev at linux.vnet.ibm.com> writes:

> Deny CLONE_PARENT|CLONE_NEWPID combination.
>
> CLONE_PARENT was probably used to implement an older threading model.

Yes it was.

> If so, for consistency with CLONE_THREAD, the CLONE_PARENT|CLONE_NEWPID
> combination should also fail with -EINVAL.

CLONE_THREAD can not work with CLONE_NEWPID because the processes share
a signal queue.

I can see a similar argument going for CLONE_SIGHAND even though there is not
as much sharing there.  I don't see how CLONE_PARENT could cause any harm.
Without CLONE_SIGHAND.

Eric

> Signed-off-by: Sukadev Bhattiprolu <sukadev at us.ibm.com>
> ---
>  kernel/pid_namespace.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-mmotm/kernel/pid_namespace.c
> ===================================================================
> --- linux-mmotm.orig/kernel/pid_namespace.c	2009-06-17 18:19:42.000000000 -0700
> +++ linux-mmotm/kernel/pid_namespace.c	2009-06-17 18:19:58.000000000 -0700
> @@ -118,7 +118,7 @@ struct pid_namespace *copy_pid_ns(unsign
>  {
>  	if (!(flags & CLONE_NEWPID))
>  		return get_pid_ns(old_ns);
> -	if (flags & CLONE_THREAD)
> +	if (flags & (CLONE_THREAD|CLONE_PARENT))
>  		return ERR_PTR(-EINVAL);
>  	return create_pid_namespace(old_ns);
>  }
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers