quoted

I have heard

 * it would give power to move other tasks to more rigid constraints.
    To which the answer is only to allow movememnt of tasks in the
   current cgroupns
 * It violates the permissions delegation model.  This one doesn't
   really make too much sense to me: in the same way the userns is root
   in its own domain, cgroups ns is effective root for the restricted
   cgroups (and only for processes within its ns).

Perhaps the question should be asked the other way around:  if we were
explicitly delegating permission to every user in the system to set up
their own sub cgroups, how would you advise it be done?

Coordinate in userspace.  Request whatever is managing the cgroup
hierarchy to set up delegation.  It's not like permission model is
fully contained in kernel on modern systems anyway.

My experience with certain systemdaemons' cgroup handling doesn't 
inspire confidence :/ (from the runC side, we've had nothing but 
issues). Also, how do you even boot into a cgroupv2 system with systemd 
(I started backporting patches to openSUSE, but it's still not booting)?

-- 
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/