Eric W. Biederman wrote: > Mike Waychison <mikew@xxxxxxxxxx> writes: > >> Cedric Le Goater wrote: >>> Dan Smith wrote: >>>> SH> (Note that in Dan's next version, he did move unshare into >>>> SH> userspace) >>>> >>>> The idealist in me still wants it to be in the kernel. However, after >>>> seeing it done I agree that it's the right thing to do, at least in >>>> this case. >>> I would say in all cases. >>> >>> as you can't unshare(CLONE_NEWPID), >> Eric, >> >> Is there a particular reason the above doesn't work? I made an attempt to >> implement it a while back, but haven't convinced myself that signals and >> re-attaching a new struct pid to a running task is correct. > > Last time I was thinking about this I figured unsharing a pid namespace would > simply place it's children in a different pid namespace, not the originating > process. > > Would that semantic be useful? It would certainly be a lot less effort than > changing the pid on a running process correctly. Hmm, that would be a little odd. I think getting the unsharing task to become pid 1 is a bit easier to understand and it makes it clear which task is the reaper for the new namespace. Otherwise the first child becomes pid 1 but it isn't the reaper. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
