Hello, On Fri, May 20, 2016 at 12:25:09PM -0400, James Bottomley wrote: > OK, so is the only problem cleanup? If so, what if I proposed that a For generic cases, it's a much larger problem. We'd have to change delegation model completely so that delegations are allowed by default, which btw can't be allowed on v1 hierarchies as some controllers don't behave properly hierarchically in v1 and would allow unpriv users to escape the constraints of its ancestors. > 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? Unfortunately, cgroup hierarchy isn't designed to support this sort of automatic delegation. Unpriv processes would be able to escape constraints on v1 with some controllers and on v2 controllers have to be explicitly enabled by root for delegated scope to have access to them. We can try to isolate these delegated subtrees and make them work transparently, which rgroup tried to do, but that collides directly with the vfs conventions (rgroups don't show up in cgroup hierarchy at all so avoid this problem). Why does an unpriv NS need to have cgroup delegated to it without cooperation from cgroup manager? If for resource control, I'm pretty sure we don't want to allow that without explicit cooperation from the enclosing scope. Overall, it feels like this is trying to work around an issue which should be solved from userland. Thanks. -- tejun -- 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
