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

Ultimately user namespace should prevent access to the systemd sockets for people wanting a secure setup without replacing /run

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.

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.

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.