[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley
<jbottomley parallels com> wrote:
> On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote:
>> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng <gaofeng 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).

The "container" as we talk about has it's own init, and no, it cannot
share /var or /run.

The stuff you talk about has nothing to do with that, it's not
different from all services or a multi-instantiated service on the
host sharing the same /run and /var.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]