I feel like the permission model makes sense in certain cases (the common
ancestor restriction, as well as the ability for a parent to apply limits to
children by setting its own limits). Neither of those are violated (if you
read the commit that introduced the common ancestor restriction).
Maybe if you give me a usecase of when it might be important that a process
must not be able to move to a sub-cgroup of its current one, I might be able
to understand your concerns? From my perspective, I think that's actually
cgroup is used to keep track of which processes belong where and
allowing processes to be moved out of its cgroup like this would be
surprising to say the least.
Would you find it acceptable if we added a bit that would make this
not happen (you could specify that a cgroup should not allow a
process to move itself to a sub-cgroup)? Or an aggregate
cgroup.procs that gives you all of the processes in the entire
branch of the tree? Surely this is something that can be fixed
without unnecessarily restricting users from doing useful things.
The reason I'm doing this is so that we might be able to _practically_ use
cgroups as an unprivileged user (something that will almost certainly be
useful to not just the container crowd, but people also planning on using
cgroups as advanced forms of rlimits).
I don't get why we need this fragile dance with permissions at all
when the same functionality can be achieved by delegating explicitly.
The key words being "unprivileged user". Currently, if I am a
regular user on a system and I want to use the freezer cgroup to
pause a process I am running, I have to *go to the administrator and
ask them to give me permission to do that*. Why is that necessary? I
Ths is of course solvable using something like libpam-cgfs or
libpam-cgm (and others). Since this sounds like a question of
policy, not mechanism, userspace seems like the right place. Is
there a downside to that (or, as Tejun put it, "delegating explicitly")?