Hi Greg, Jeff,
Is see that there are temporary safeguards in place to disable cgroups v2 if there is no root (by checking can_switch_ids()), but this change should be independent of that.
This would instead be just to allow the executing user in the slot to create new sub-cgroups in case the cgroups tree has already been set up - setting aside the specifics if this was done with/without elevated privileges beforehand.
For this to work, the executing user of the slot must be giving ownership of three things in the fs: the newly created cgroup for the slot (this will allow the user to create new sub-cgroups), the cgroup.procs file (this allows moving
processes in the current cgroup to the new sub-cgroups), and lastly the cgroups.subtree_control file (allows delegating controllers, e.g. memory, to the sub-cgroups)
(example).
The remaining files can remain owned by root.
The benefit of the above approach is that resources can only be subdivided and delegated down. While it is possible for a sub-cgroup further down to request more resources than given, the cgroup above will still enforce its limit,
preventing it from gaining these. The only way to request more resources would be by modifying the cgroup that is a level up -- and the top cgroup, outside the one given to the slot, remains (and should be) owned by root.
Best regards,
-Maxim StoretvedtFrom: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Jeff Templon <templon@xxxxxxxxx>
Sent: 27 September 2023 09:09 To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx> Cc: Irakli Chakaberia <irakli.chakaberia@xxxxxxx> Subject: Re: [HTCondor-users] Unprivileged cgroups v2 & delegation Hi,
How does this work? Giving ownership of the assigned cgroup, I think that it would be useful (and okay) to allow an unprivileged user to subdivide that assigned cgroup into pieces. It would definitely NOT be okay to give a user the ability to expand
the cgroup past what was assigned (please give me another 32 GB ….)
JT
|