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  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 11:30:58 -0400
From:	James Bottomley <>
To:	Tejun Heo <>, Aleksa Sarai <>
Cc:	Li Zefan <>,
	Johannes Weiner <>,
	Aleksa Sarai <>,,,
Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new
 cgroup namespaces

On Fri, 2016-05-20 at 08:22 -0700, Tejun Heo wrote:
> On Sat, May 21, 2016 at 12:48:48AM +1000, Aleksa Sarai wrote:
> > Are there any comments on this version of the patchset? I thought 
> > we had reached an agreement that the underlying feature (allowing a
> > process to manage its own cgroups) was useful. Is there a better 
> > way of solving this problem, that I don't know of?
> I still don't see why this is necessary.  Delegation is done through
> chmodding.  There's no reason to deviate for namespaces.

Given it's merge window time, I haven't yet had time to look at the
patch, but I can tell you why it (or something like it) is necessary:
unprivileged containers need to be able to set up cgroups as well as
namespaces, so we do need a way for the user ns owner to modify cgroups
in their default configuration otherwise cgroups just won't fit into
the unprivileged model.  Whether this should be through the cgroup ns
is up for debate, as is how we should actually allow this to happen and
what we should present to the user ns owner, but we do need a way to do

Delegation can't be through chmodding in this case because the user ns
owner can't chmod something owned by init_user_ns root.


Powered by blists - more mailing lists