On Fri, Jan 20, 2017 at 11:29:54AM -0500, Tejun Heo wrote: > Along with the write access to the cgroup.procs or tasks file, cgroup > has required the writer's euid, unless root, to match [s]uid of the > target process or task. On cgroup v1, this is necessary because > there's nothing preventing a delegatee from pulling in tasks or > processes from all over the system. > > If a user has a cgroup subdirectory delegated to it, the user would > have write access to the cgroup.procs or tasks file. If there are no > further checks than file write access check, the user would be able to > pull processes from all over the system into its subhierarchy which is > clearly not the intended behavior. The matching [s]uid requirement > partially prevents this problem by allowing a delegatee to pull in the > processes that belongs to it. This isn't a sufficient protection > however, because a user would still be able to jump processes across > two disjoint sub-hierarchies that has been delegated to them. > > cgroup v2 resolves the issue by requiring the writer to have access to > the common ancestor of the cgroup.procs file of the source and target > cgroups. This confines each delegatee to their own sub-hierarchy > proper and bases all permission decisions on the cgroup filesystem > rather than having to pull in explicit uid matching. > > cgroup v2 has still been applying the matching [s]uid requirement just > for historical reasons. On cgroup2, the requirement doesn't serve any > purpose while unnecessarily complicating the permission model. Let's > drop it. > > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> Applied to cgroup/for-4.11. 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
