Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 7, 2013 4:41 UTC (Sat) by dlang (guest, #313)
In reply to: Another daemon for managing control groups by Cyberax
Parent article: Another daemon for managing control groups

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

to post comments

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.