Messages in this thread | | | Subject | Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces | From | Aleksa Sarai <> | Date | Sat, 21 May 2016 02:29:55 +1000 |
| |
>> This is stemming from the fact that an unpriv application can't >> create its sub-cgroups without explicit delegation from the root and >> that has always been an explicit design choice. >> It's tied to who's responsible for cleanup afterwards and what >> happens when the process gets migrated to a different cgroup. The >> latter is an important issue on v1 hierarchies because migrating >> tasks sometimes is used as a way to control resource distribution. > > OK, so is the only problem cleanup? If so, what if I proposed that a > cgroup directory could only be created by the owner of the userns > (which would be any old unprivileged user) iff they create a cgroup ns > and the cgroup ns would be responsible for removing it again, so the > cgroup subdirectory would be tied to the cgroup namespace as its holder > and we'd use release of the cgroup to remove all the directories?
The only question I'd have is how would we deal with visibility (and should a "parent" cgroup namespace be able to modify things inside the cgroup?). And of course, how would that interact with VFS?
-- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
| |