Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 5, 2013 2:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Parent article: Another daemon for managing control groups

> Depending on permissions, any process may be able use that interface to set up its own hierarchy of groups, which is one of the problems with the existing implementation, according to cgroup co-maintainer Tejun Heo and others.

Can ANYBODY describe the relevant problems???

I've been hearing this statement about problems with cgroup delegation about 27863 times but I haven't been able to find what the problems are. Apart from the utterly trivial "starve your siblings" one.

to post comments

Another daemon for managing control groups

Posted Dec 5, 2013 5:31 UTC (Thu) by Fowl (subscriber, #65667) [Link] (8 responses)

Yes I'd very much like to see a comprehensive overview of what exactly is wrong with the status quo. It seems that the kernel is the perfect place to mediate between processes, delegate system resources and enforce security... I mean we don't have a user space "file manager".

Or is the current implementation unworkable somehow?

Another daemon for managing control groups

Posted Dec 5, 2013 7:59 UTC (Thu) by ovitters (guest, #27950) [Link] (6 responses)

It was explained at least a few times in previous LWN articles AFAIK. Think as recently as 2-4 weeks or so.

Another daemon for managing control groups

Posted Dec 7, 2013 4:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

NO IT WASN'T!

The only scenario explained was a brain-dead "starve your siblings" one. Which is extremely easy to avoid.

Another daemon for managing control groups

Posted Dec 7, 2013 4:41 UTC (Sat) by dlang (guest, #313) [Link] (2 responses)

> The only scenario explained was a brain-dead "starve your siblings" one. Which is extremely easy to avoid.

In the comments here I have heard one other issue, the fact that this turns kernel-internal APIs into something accessed by unprivileged users, and those interfaces may not have been hardened suitably.

Now, while I agree this is a valid concern, the 'solution' of cut off all possible access except through a single userspace daemon does not seem like the appropriate long-term answer.

Another daemon for managing control groups

Posted Dec 7, 2013 6:21 UTC (Sat) by raven667 (guest, #5198) [Link] (1 responses)

> Now, while I agree this is a valid concern, the 'solution' of cut off all possible access except through a single userspace daemon does not seem like the appropriate long-term answer.

I think you are exactly right, and I would guess that Tejun Heo would agree with you, but the time and effort it is going to take to build a cgroup API in kernel space which could be delegated to untrusted users and have some guarantees that they couldn't cause trouble will take many years of effort and probably a thorough rewrite of the cgroup implementation to put in appropriate policy and access control.

In the mean time the single-userspace-manager approach will both help solve the immediate issue and provide very useful operational experience which will inform the choices what that eventual kernel API should look like based on the real-world cases of how the userspace managers are actually used.

Another daemon for managing control groups

Posted Dec 7, 2013 8:44 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

What is so freakingly complicated in delegating?

Cgroups API is not something magical with tons of different settings! There are maybe around 50 user changeable settings in _total_ for all cgroups and most of them are uncomplicated.

Sure, there might be subtle race conditions or something, but solution for them is not to hide our head in sand, but to solve them.

Look, /proc is much more complicated than /sys/fs/cgroup and yet it has been secured adequately for non-privileged users to create their own namespaces. Of course, Lennart's way for this would be to create NamespaceD with DBUS-based interface and pull it into SystemD.

Another daemon for managing control groups

Posted Dec 7, 2013 6:25 UTC (Sat) by raven667 (guest, #5198) [Link] (1 responses)

Hey man, no point in arguing about what is or isn't here with us, you should just have this out with Tejun Heo, you can explain to him how his understanding of what the core cgroup failings are totally wrong and how any problems he believes he has uncovered are actually extremely easy to avoid. I'm sure he'll be grateful for saving him so much work once you explain that all the design flaws he uncovered are actually features.\

I hope you take my sarcasm in the gentile way it was intended 8-).

Another daemon for managing control groups

Posted Dec 7, 2013 8:51 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

I sent him a message some time ago. It has been ignored (as I suspected it would be). I'm preparing a long message to LKML, but I'm sure it's going to be ignored too.

My company provides a platform for hundreds of customers and we depend heavily on cgroups for our infrastructure. That's why it worries me that cgroups developers simply declare that cgroups ABI is somehow magically insecure and can NOT be fixed at all. And the only solution is to develop a One Daemon To Rule Them All with an API that almost, but not quite completely replicates the filesystem interface.

Another daemon for managing control groups

Posted Dec 10, 2013 22:24 UTC (Tue) by Fowl (subscriber, #65667) [Link]

(this was a request for more LWN content, not an attack on any of the players)

Another daemon for managing control groups

Posted Dec 7, 2013 21:07 UTC (Sat) by hallyn (subscriber, #22558) [Link]

I can't, and agree with your position. We have two practical needs for the manager for lxc. First is that lxc itself not have to worry about nesting for children - it just wants containers to be under itself regardless if what its current cgroup is. Don't want that code in lxc. Second is user namespaces - you cannot make changes to devices cgroup settings if you are root in a child userns (need sys_admin targeted at init_user_ns), and a patch to allow this (which should be safe due to in-kernel hierarchical constraints) was rejected. The manager handles that for us.

Well, one danger is simply too-deep nesting of cgroups by unpriv users which could exhaust kmem. That and yours are all I know of.