Another daemon for managing control groups

And let me post my rants from the comments:

I've been using delegation to !priv users with the current cgroup design just fine. It works as expected - I simply give permissions to a cgroup subtree to a user and they can do whatever they want.

I have heard the claim that cgroup delegation is uber-insecure and will eat your pets for lunch about 100^500 times by now. But somehow people always omit the exact details of the horrible gaping security holes. Except for the brain-damaged "starve your siblings" scenario and non-hierarchical cgroups (which are a mis-feature in themselves).

Let's see your technical objections:

1) "Putting processes into an undefined state and fouling up the debugger". Boohoo. So a !priv user can mess with their debugger. Horrible. And totally unprecedented, since ptrace is a nice rock-solid interface that always works flawlessly.

2) Unlimited vmalloc - totally a kernel issue that MUST be fixed anyway.

And your non-technical objections: cgroup ABI must be treated as an ABI. That ALREADY is true, systemd is NOT going to be the single user of the cgroups ABI and so it must be stable.

Next, let's see the requirements for the central cgroups daemon. It must support delegation to other users. At minimum, to support containers running old versions of systemd or other cgroup users.

How can this be done? I envision a way to delegate a subtree of the whole cgroups tree and allow the delegated software to be limited to using it.

So you need to have a way to isolate a part of DBUS tree and make sure only authorized users can access it.

Then there's a question of security - how do I audit cgroups delegation tree? Is there an audit API?

Can I use my favorite AppArmor (systemd is going to fully support AppArmor, right?) policies to make sure that only one process in my cgroups+namespaces based container is allowed to tinker with cgroups? How do I make sure that my browser can't ask for a delegated cgroups tree using this nice systemd-based DBUS interface?

Basically, ALL these issues are solved nicely with the classic Linux filesystem-based interfaces. And trying to solve them another way would just generate a solution isomorphic to a filesystem tree. Except it'll be stupid and buggy.