[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lxc-devel
Subject:    [lxc-devel] Nested namespaces
From:       jean-tiare.le-bigot () ovh ! net (Jean-Tiare LE BIGOT)
Date:       2014-09-29 7:19:09
Message-ID: 542907ED.5030303 () ovh ! net
[Download RAW message or body]

Cgroups and Namespaces are two completely different mechanism of the 
Linux kernel.

Cgroups is for resource isolation while Namespaces are for kernel 
datastructure isolation.

In other words, unsharing a namespace will have no impact on cgroups: 
all child processes are added to current cgroup by default.

On 09/29/2014 07:12 AM, Riya Khanna wrote:
> Thanks!
> 
> Does this mean that the new namespaces will be subject to new cgroups quota (as \
> defined by the new namespaces) or parent namespaces cgroups apply to the child as \
> well? 
> Thanks,
> Riya
> 
> > On Sep 28, 2014, at 11:24 PM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> > 
> > > On Sun, Sep 28, 2014 at 06:31:18PM -0500, riya khanna wrote:
> > > Hi,
> > > 
> > > As I understand, kernel currently supports six namespaces. Is it
> > > possible for a process inside a container (running with different
> > > namespaces - all six) to escape the container by unshare() 'ing ?
> > > 
> > > Would this be different for privileged/unprivileged containers?
> > > 
> > > Thanks,
> > > Riya
> > 
> > It's certainly possible to unshare namespaces from within a container
> > but that's a feature, not an issue.
> > 
> > So you can't "escape" by unsharing, you can just get some new namespaces
> > setup which are children of your current one.
> > 
> > --
> > Stéphane Graber
> > Ubuntu developer
> > http://www.ubuntu.com
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
> 

-- 
Jean-Tiare, shared-hosting team


[prev in list] [next in list] [prev in thread] [next in thread]