Mike Waychison <mikew@xxxxxxxxxx> writes: > 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. For very lightweight pid namespaces that may be desirable, and that is where all of this conversation originally started. I am happy to set the starting pid to 2 to avoid confusion on that point. One of the other problems with changing the pid is that user space in general glibc in particular can not cope with the pid of a process changing. My memories are foggy at the moment but I do know that on the several occasions we have looked at unshare of the pid namespace it has failed due to kernel issues. I also remember I was close to having resolved the issues of unsharing the pid namespace if we did not change the pid of processing calling unshare. You did not answer my question. I don't quite see how you were envisioning using unsharing the pid namespace as part of restart so I can't tell if my proposed semantics would work for that case. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers