Messages in this thread | | | Date | Mon, 5 Dec 2011 23:38:31 +0100 | From | "Miquel van Smoorenburg" <> | Subject | Re: [PATCH 0/1][V3] Handle reboot in a child pid namespace |
| |
In article <xs4all.20111205205035.GB7422@redhat.com> you write: >On 12/05, Daniel Lezcano wrote: >> >> On 12/04/2011 10:27 PM, Henrique de Moraes Holschuh wrote: >> > On Sun, 04 Dec 2011, Daniel Lezcano wrote: >> > Daniel, can you address Miquel's concern? Is it a valid concern, or >> > not? I assume CAP_REBOOT functionality is still in place inside the >> > container, so it really does look like userspace would need to know >> > whether it should drop CAP_REBOOT or not, in order to automatically use >> > the new feature. >> >> Hmm, I missed its email. > >Me too... so I am not sure I really understand the problem.
In order to use this new functionality, a container has to have the CAP_REBOOT capability.
So if that container setup runs on a modern kernel with this patch applied all is well and sys_reboot() will just reboot the container. But on an older kernel, that sys_reboot() call will reboot the host. You really really want to prevent that.
So there should be a way for the system setting up the container (e.g. lxc-start) to know if this new reboot-the-container-instead- of-the-host is implemented. If not, it should drop CAP_REBOOT.
That's why I proposed adding a LINUX_REBOOT_CMD_ISCONTAINER (or whatever) pseudo command for sys_reboot that would only return 0 for the reboot-the-name-space version of sys_reboot().
lxc-start or equivalent would then do:
if (sys_reboot(LINUX_REBOOT_CMD_ISCONTAINER) != 0) cap_drop(CAP_REBOOT);
Mike.
| |