On 2024/8/14 3:02, Tejun Heo wrote:
Hello,
On Mon, Aug 12, 2024 at 06:57:06PM +0200, Michal Koutný wrote:
...
You could also have increased the ancestral limit (if there was any)
echo max > dlgt_grp_ns/pids.max // similarly allowed
If you're a root (or otherwise have sufficient permissions) and you can
_see_ an ancestral cgroup, you can write to its attributes according to
permissions. Thus the delegation works via cgroup ns (in)visibility but
cgroup ns root is visible on both sides of the boundary hence the extra
check.
Yeah, the intended usage scenario w/ NS delegation is that the delegatee
won't be able to see the ancetral cgroups beyond the delegation point. Chen,
is this from an actual usecase? If so, can you describe what's going on?
Thanks.
Hi，TJ， We plan to use delegation in cgroup-v2, so I am conducting some
tests.
As doc mentions 'Because the resource control interface files in a given
directory control the distribution of the parent's resources, the
delegatee shouldn't be allowed to write to them.' However I found a root
can write parent's file(cgroup.subtree_control) to change the resource
limits(a fraudulent method). I believe this could pose a risk in some
scenarios where a root enters a new cgroup ns without unmounting
original cgroup system, and it can break limitations. For instance,
running a docker with --privileged, could this be a risk?
So I sent this patch to discuss whether this case should be addressed?
Thanks,
Ridong
