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

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(a)cn.fujitsu.com&gt; >>>>> --- >>>>> 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.