Quoting Dan Smith (danms@xxxxxxxxxx): > 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. core_dump vs gdb? :) > 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, Had to check, but yes you're right. > 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? Actually we can go a step further and say we expect user-space to set the hostname, which otherwise (admittedly in a container) the user, with your patch, can now do unprivileged, right? In particular, once it comes to setting up network devices for a container at restart, I think we'll find userspace a far easier place to work. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
