linux-kernel - Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 May 2016 09:17:59 -0700
From:	Tejun Heo <tj@...nel.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Aleksa Sarai <asarai@...e.de>, Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Aleksa Sarai <cyphar@...har.com>, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, dev@...ncontainers.org
Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new
 cgroup namespaces

Hello, James.

On Fri, May 20, 2016 at 12:09:10PM -0400, James Bottomley wrote:
> I think it's just different definitions.  If you take on our definition
> of being able to set up a container without any admin intervention, do
> you see our problem: we can't get the initial delegation of the
> hierarchy.

Yeah, I can see the difference but we can't solve that by special
casing NS case.  This is stemming from the fact that an unpriv
application can't create its sub-cgroups without explicit delegation
from the root and that has always been an explicit design choice.
It's tied to who's responsible for cleanup afterwards and what happens
when the process gets migrated to a different cgroup.  The latter is
an important issue on v1 hierarchies because migrating tasks sometimes
is used as a way to control resource distribution.

Thanks.

-- 
tejun