Mike Waychison wrote: > Serge E. Hallyn wrote: >> Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): >>> Ok. I see what you are trying to accomplish with this and honestly I >>> think it is silly. >>> >>> We should start the threads we need in the kernel, and if we need to >>> run clone_pid fine. I am not comfortable exporting clone_with_pid to >>> user space. >> Even if we create the task tree in userspace, I don't see why we >> can't have the parent of each nested pid_ns pass CLONE_NEWPID to >> clone_with_pid() instead of doing clone first and then unsharing >> the pidns? >> >> As for clone_with_pid(), I don't particularly like the semantics, >> but as was discussed over IRC, we could have clone_with_pid() >> return -EINVAL unless it is called while it is called from a task >> inside a restarting container. (and -EPERM if setting a pid in >> a pid_ns which was not created as part of the container) Eric >> do you dislike that any less? > > Wouldn't this mean the kernel would have to track which namespaces are > part of a restart and which aren't? Seems a little kludgy to me. We are talking only about pidns, right ? So we need to keep track of a single pidns - the top level for the restarting container; that's the container init. We can, e.g., mark it with a flag. We can then follow the hierarchy up through pidns until we reach the one marked, or the topmost, and grant (or deny) permission. Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
