[Devel] Re: [PATCH] [RFC] c/r: Add UTS support

[Serge E. Hallyn]

Quoting Dan Smith (danms at us.ibm.com):
> 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 at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers