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

Daniel P. Berrange berrange at redhat.com
Thu Aug 22 10:18:14 UTC 2013


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.


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 :|




More information about the libvir-list mailing list