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 12:25:09 -0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Tejun Heo <tj@...nel.org>
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

On Fri, 2016-05-20 at 09:17 -0700, Tejun Heo wrote:
> 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.

Great, we agree on the problem definition ... as I said, I'm not saying
this patch is the solution, but it gives us a starting point for
exploring whether there is a solution.

>   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.

OK, so is the only problem cleanup?  If so, what if I proposed that a
cgroup directory could only be created by the owner of the userns
(which would be any old unprivileged user) iff they create a cgroup ns
and the cgroup ns would be responsible for removing it again, so the
cgroup subdirectory would be tied to the cgroup namespace as its holder
and we'd use release of the cgroup to remove all the directories?

James