lkml.org 
[lkml]   [2011]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2011-12-05 23:41    [W:0.626 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site