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@xxxxxxxxxxxxxx> >>>>>> --- >>>>>> 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... -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list