Re: [libvirt] [PATCH] lxc: Cleaning up mount setup

On Thu, Jan 08, 2015 at 03:02:59PM +0100, Richard Weinberger wrote: > Am 08.01.2015 um 14:45 schrieb Daniel P. Berrange: >> On Thu, Jan 08, 2015 at 02:36:36PM +0100, Richard Weinberger wrote: >>> Am 08.01.2015 um 14:02 schrieb Daniel P. Berrange: >>>> We have historically done a number of things with LXC that are >>>> somewhat questionable in retrospect >>>> >>>> 1. Mounted /proc/sys read-only, but then mounted >>>> /proc/sys/net/ipv* read-write again >>>> 2. Mounted /sys read only >>>> 3. Mount /sys/fs/cgroup/NNN/the/guest/dir to /sys/fs/cgroup/NNN >>>> 4. FUSE mount on /proc/meminfo >>>> >>>> Items 1 & 2 are pointless as they offer no security benefit either >>>> with or without user namespaces. Without userns it is always insecure, >>>> with userns it is always secure, no matter what the mount state is. >>> >>> I agree. Thanks a lot for addressing this, Daniel! >>> >>>> Item 3 is some what dubious, since /proc/self/cgroup paths for >>>> processes are now not visible at /sys/fs/cgroup. This really >>>> confuses systemd inside the container making it create a broken >>>> layout >>> >>> The question is, how to support systemd in containers? >>> >>> As of now I'm not aware of a working concept. >>> With current libvirt it kind of works but recently I found a very nasty issue: >>> See: https://www.redhat.com/archives/libvir-list/2014-November/msg01090.html >> >> That reply from Lennart suggests systemd should pretty much work, >> albeit in a hacky way. > > What hack to you mean? Lennarts reply detailing their workaround hacks:

> My use case is different. I need most of the time at least an init. > And if the distro is systemd based.... > Yeah but we have to warn the user that she is doing something insecure > if no mappings are set up. Ultimately I think that's a docs problem, or something that a higher level app needs to deal with. eg OpenStack should setup LXC such that user namespaces are unconditionally enabled all the time, even if that's not the case in libvirt itself. OpenStack manages the whole machine, so it has enough context to do the setup that libvirt cannot do.