[libvirt] [PATCH] LXC: mount a fresh /run directory for container

[Gao feng]

On 08/22/2013 06:18 PM, Daniel P. Berrange wrote:
> On Thu, Aug 22, 2013 at 06:07:50PM +0800, Gao feng wrote:
>> On 08/22/2013 05:41 PM, Daniel P. Berrange wrote:
>>> On Thu, Aug 22, 2013 at 08:57:49AM +0800, Gao feng wrote:
>>>> On 08/21/2013 05:31 PM, Daniel P. Berrange wrote:
>>>>> On Wed, Aug 21, 2013 at 04:22:29PM +0800, Gao feng wrote:
>>>>>> The unix socket file /run/systemd/private is used to
>>>>>> send reboot/shutdown messages. and since this type of
>>>>>> unix sockets are not per net namespace , they are
>>>>>> global resources. systemctl in container can use
>>>>>> this unix socket to send shutdown message to the
>>>>>> systemd-shutdownd running on host. finally the
>>>>>> host will be poweroff.
>>>>>>
>>>>>> this problem occurs when container shares the same
>>>>>> root directory with host.
>>>>>>
>>>>>> this patch umount host's /run directory and mount
>>>>>> the /run directory of container as tmpfs.
>>>>>>
>>>>>> Signed-off-by: Gao feng <gaofeng at cn.fujitsu.com>
>>>>>> ---
>>>>>>  src/lxc/lxc_container.c | 5 +++++
>>>>>>  1 file changed, 5 insertions(+)
>>>>>
>>>>> I don't think we should be doing this by default. IMHO this is something
>>>>> the mgmt app / admin should take care of it they want to have separate
>>>>> /run.
>>>>>
>>>>> You may be preventing access to the systemd socket by doing this, but
>>>>> equally you can be breaking any number of other valid use cases by
>>>>> hiding the host's /run
>>>>
>>>> We can't assume user know the root reason why shutdown in container will
>>>> shut down the host. they don't know it's because of container shares the
>>>> /run/ directory with host. This will confuse them and bring bad image to
>>>> them. We have lxcContainerHasReboot in libvirt, and it did tell user that
>>>> "Containerized reboot support is available", but the fact is reboot in
>>>> container will reboot host.
>>>>
>>>> and the /run directory is mounted as tmpfs on host. it means the files
>>>> under /run are temporary, I don't think it's meaningful to share these
>>>> files with container.
>>>>
>>>> If someone really want to share host's /run directory with container, he
>>>> should add this filesystem configuration to the domain xml.
>>>
>>> Quite simply, no.
>>>
>>> If the user asks for '/', then that's what they'll get. If they want
>>> to hide /run they can do so.
>>>
>>
>> Users don't know why sharing root directory with host will cause host
>> can be rebooted from container. pid namespace is enabled by libvirt lxc and
>> actually libvirt did say that "Containerized reboot support is available".
>> it's hard for user to find out that container shouldn't share /run directory
>> with host. it's easy for them to find out some files are leaked under /run
>> directory for container, and then add this filesystem configuration to the
>> domain xml file.
>>
>>
>> And I still think it really make no sense for container to share /run
>> directory with host.
>>
>>> What you're describing is a usability policy issue, solution to which
>>> belongs in the tools.
>>>
>>> If you are editting XML directly to configure guests, it is expected
>>> that you know what you are doing.
>>>
>>>>> Ultimately user namespace should prevent access to the systemd
>>>>> sockets for people wanting a secure setup without replacing /run
>>>>>
>>>>
>>>> Some people may think user namespace is too strict, they may dislike
>>>> to enable user namespace, just like they may want share net namespace
>>>> with host. They have rights to start a container which shares same
>>>> user namespace with host.
>>>
>>> They have the ability to specify a new mount of /run if they so desire.
>>>
>>
>> Yep, but they don't know how to fix this reboot-problem until they read
>> this thread or some documents somewhere.
>>
>> I think though users know sharing root directory with host will bring bad influence.
>> I guess they must don't know this will make their host can be powered off by the
>> user in container.
> 
> The majority of users will not be creating XML configs for LXC
> directly. They will use tools like virt-sandbox-service, or
> virt-install, which can take care todo the right setup for their
> use cases.
> 
> 

Hmm, indeed two fujitsu guys asked me why reboot in container will cause host to be
rebooted...