Hello, Aleksa. On Thu, Jul 21, 2016 at 08:58:32AM +1000, Aleksa Sarai wrote: > I'm not sure what you mean by "steal". The user doing the migration owns the
In the sense that the ancestor cgroup can be modified by one of its descendants even when that descendant doesn't have enough permission to modify the ancestor. > process, so I would argue that they aren't "stealing" anything. While a > higher level process might not know where precisely in the hierarchy the > process is, they'll know it that it must be a sub-cgroup of the one they > were put in (meaning the parent can still impose restrictions without any > issue). Hmmm... it's not just about the ownership of the process itself. If it had been, we wouldn't have bothered with permission model on cgroup hierarchy itself. It's also about who is allowed to modify a given cgroup and what you're proposing violates that. > If you want, we can make it so that an unprivileged user migrating processes > to a child cgroup only works if you're in the same cgroup namespace (and > have CAP_SYS_ADMIN in the pinned user namespace, etc). The current setup > would obviously still work, but you'd add a permission for users that just > want to be able to limit their own processes. IIRC we need to update > cgroup_procs_write_permission() anyway. By having the cgroup namespace > requirement, you'd definitely have to "own" the process in every sense of > the word I can imagine. Maybe I'm misunderstanding but I can't see how that would change the situation in a significant way. Thanks. -- tejun
