Quoting Dan Smith (danms@xxxxxxxxxx): > NL> I'd like there to be some discussion about this, because namespace > NL> creation seems like a significant addition to the semantics of > NL> restart as I understand it. > > Indeed. > > NL> Is namespace creation during restart unavoidable, or merely > NL> desirable? Is there a case for requiring the user to provide a > NL> suitable namespace environment before attempting restart? > > Information about the namespaces has to be saved at checkpoint time no > matter what, right? I guess I don't see any compelling reason to not > have the restart operation replicate the environment of the original > process. Otherwise we require userspace to read and interpret the > checkpoint stream and selectively feed the bits that the kernel is > responsible for to the kernel and process the rest itself (or have the > kernel ignore those records). Well we haven't yet settled the Oren-vs-Alexey argument of who sets up the new process tree. Oren would have userspace parse the checkpoint file, do a bunch of clones to recreate the process tree, then have each task call sys_restart(). Alexey would have one task call sys_restart() where the system call then recreates the process tree. You seem to be doing half of each :) I think if we go with Oren's route then we should use CLONE_NEWPID etc flags from userspace to set up the proper relationships. If we go with Alexey's, then the kernel can just hand-create the nsproxies somewhat the way you are doing using copy_namespaces(). > What's the argument for depending on userspace to set this up? Well it forces restart to go through the established userspace API's when creating resources (in this case, tasks and namespaces) which means any existing security guarantees are leveraged. If we go with your patch, we suddenly have to worry about whether restart is a way to get around the CAP_SYS_ADMIN requirements for cloning a new namespace. Just as an example. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
