Am 08.01.2015 um 15:06 schrieb Daniel P. Berrange: > 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: Oh yes. But these do not work as I've stated in the mail. My containers show thousands of orphaned login sessions and render the container unusable after some time. >> 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. I don't run OpenStack but i tend to agree. :-) Thanks, //richard -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list