Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 5, 2013 7:59 UTC (Thu) by ovitters (guest, #27950)
In reply to: Another daemon for managing control groups by Fowl
Parent article: Another daemon for managing control groups

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

to post comments

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.