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. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list