On 11/06, Eric W. Biederman wrote:
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1174,7 +1174,7 @@ static struct task_struct *copy_process(unsigned long
> clone_flags,
> * do not allow it to share a thread group or signal handlers or
> * parent with the forking task.
> */
> - if (clone_flags & (CLONE_SIGHAND | CLONE_PARENT)) {
> + if (clone_flags & (CLONE_SIGHAND)) {
> if ((clone_flags & (CLONE_NEWUSER | CLONE_NEWPID)) ||
> (task_active_pid_ns(current) !=
> current->nsproxy->pid_ns_for_children))
OK, agreed. I failed to find any problem with CLONE_PARENT with
CLONE_NEWUSER or after setns. And the main point of 40a0d32d1eaf
was "make them consistent", not "tighten up".
Besides, this doesn't differ too much from setns + fork() && exit(),
the grandchild will have the new namespace and reparented.
Acked-by: Oleg Nesterov <o...@redhat.com>
> Changing the CLONE_SIGHAND into CLONE_THREAD will need to happen in a
> separate patch. It isn't stable material, and so far there is no
> compelling use case for it.
Yes. Again, 40a0d32d1eaf chose CLONE_SIGHAND to unify CLONE_NEWUSER/setns
cases, copy_process() used this check. And in fact I voted for CLONE_THREAD
from the very beginning, it was you who suggested to use CLONE_SIGHAND
instead ;) OTOH, it was probably right to not relax the restrictions we
already had.
Oleg.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
