[libvirt] [PATCH] LXC: mount a fresh /run directory for container
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@cn.fujitsu.com> --- src/lxc/lxc_container.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 8abaea0..aae8e6a 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -772,6 +772,10 @@ static int lxcContainerMountBasicFS(void) { "sysfs", "/sys", "sysfs", NULL, MS_BIND|MS_REMOUNT|MS_RDONLY }, { "securityfs", "/sys/kernel/security", "securityfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV }, { "securityfs", "/sys/kernel/security", "securityfs", NULL, MS_BIND|MS_REMOUNT|MS_RDONLY }, + /* We should mount /run directory as tmpfs, since it contains some + * global files such as /run/systemd/private which can be used to + * send reboot/shutdown message from container to host. */ + { "tmpfs", "/run", "tmpfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV }, #if WITH_SELINUX { SELINUX_MOUNT, SELINUX_MOUNT, "selinuxfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV }, { SELINUX_MOUNT, SELINUX_MOUNT, NULL, NULL, MS_BIND|MS_REMOUNT|MS_RDONLY }, @@ -1526,6 +1530,7 @@ static int lxcContainerSetupPivotRoot(virDomainDefPtr vmDef, if (STREQ(root->src, "/") && (lxcContainerUnmountSubtree("/sys", false) < 0 || lxcContainerUnmountSubtree("/dev", false) < 0 || + lxcContainerUnmountSubtree("/run", false) < 0 || lxcContainerUnmountSubtree("/proc", false) < 0)) goto cleanup; -- 1.8.3.1
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@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 Ultimately user namespace should prevent access to the systemd sockets for people wanting a secure setup without replacing /run 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 :|
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@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.
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.
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@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. 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. 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 :|
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@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. Thanks
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@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 :|
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@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.
Hmm, indeed two fujitsu guys asked me why reboot in container will cause host to be rebooted...
participants (2)
-
Daniel P. Berrange -
Gao feng