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/ -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
