[libvirt] [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

James Bottomley jbottomley at parallels.com
Sun Aug 25 17:16:17 UTC 2013


On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote:
> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng <gaofeng at cn.fujitsu.com> wrote:
> > On 08/21/2013 03:06 PM, Eric W. Biederman wrote:
> 
> >> I suspect libvirt should simply not share /run or any other normally
> >> writable directory with the host.  Sharing /run /var/run or even /tmp
> >> seems extremely dubious if you want some kind of containment, and
> >> without strange things spilling through.
> 
> Right, /run or /var cannot be shared. It's not only about sockets,
> many other things will also go really wrong that way.

This is very narrow thinking about what a container might be and will
cause trouble as people start to create novel uses for containers in the
cloud if you try to impose this on our current infrastructure.

One of the cgroup only container uses we see at Parallels (so no
separate filesystem and no net namespaces) is pure apache load balancer
type shared hosting.  In this scenario, base apache is effectively
brought up in the host environment, but then spawned instances are
resource limited using cgroups according to what the customer has paid.
Obviously all apache instances are sharing /var and /run from the host
(mostly for logging and pid storage and static pages).  The reason some
hosters do this is that it allows much higher density simple web serving
(either static pages from quota limited chroots or dynamic pages limited
by database space constraints) because each "instance" shares so much
from the host.  The service is obviously much more basic than giving
each customer a container running apache, but it's much easier for the
hoster to administer and it serves the customer just as well for a large
cross section of use cases and for those it doesn't serve, the hoster
usually has separate container hosting (for a higher price, of course).

James





More information about the libvir-list mailing list