[PATCH] [RFC] c/r: Add UTS support
orenl at cs.columbia.edu
Wed Mar 18 01:27:21 PDT 2009
Dan Smith wrote:
> SH> Well it forces restart to go through the established userspace
> SH> API's when creating resources (in this case, tasks and namespaces)
> SH> which means any existing security guarantees are leveraged.
> That's a very valid point. However, it still seems unbalanced to make
> checkpoint a completely in-kernel process and restart an odd mix of
> the two with potentially more confusing semantics and requirements.
There are other reasons to allow restart to be not fully symmetric
with respect to checkpoint. For example, if you have a smart(er) user
space application that wants to provide the restart some of the resources
pre-constructed, allowing much flexibility (already requested by people)
for the restart provdure (E.g., when doing distributed checkpoint, or
when restarting a special device whose).
See my post:
> SH> If we go with your patch, we suddenly have to worry about whether
> SH> restart is a way to get around the CAP_SYS_ADMIN requirements for
> SH> cloning a new namespace. Just as an example.
> Why? The call to copy_namespaces() will do the CAP_SYS_ADMIN check,
> right? Maybe your point is that in the restart implementation of
> other namespace types we could potentially slide in a call to
> something else that has already assumed the check has been made? I
> think that doing the obligatory copy_namespaces() during the restart
> helps catch that case early and explicitly, no?
More information about the Containers