Re: [PATCH] cgroup/cpuset: Creating or adding CPUs to partition not allowed without privilege

[Waiman Long <longman@redhat.com>]

On 4/28/26 11:19 AM, Waiman Long wrote:
> On 4/28/26 3:58 AM, Michal Koutný wrote:
>> Hi Waiman.
>>
>> On Mon, Apr 27, 2026 at 11:34:39PM -0400, Waiman Long 
>> <longman@redhat.com> wrote:
>>> Creation of a cpuset partition or adding more CPUs to an existing
>>> partition will take CPUs away from other cpusets outside of the
>>> partition leaving less CPUs for the others. So it is a privileged
>>> operation that non-privileged users shouldn't be allowed to do.
>>>
>>> Currently, remote partition code has check for CAP_SYS_ADMIN capability
>>> before allowing such operations, but not for local partition.
>> Remote partitions need such a check because their CPUs are sourced from
>> the global supply (top level) without
>>
>>> This leaves a security hole in case cpuset.cpus.partition of a cpuset
>>> is chown'ed to a non-root user and its parent cpuset happens to be a
>>> partition root.
>> I wouldn't say this difference between remote and local partitions is a
>> security hole [1].
> OK, I will tone down the description.
>>
>> Consider this -- cgroup a is created by root (admin) and its resources
>> are constrained by root's policy. However, what happens in a subtree is
>> irrelevant from that top level view.
>>
>> # setup            // owner
>> a/cpuset.partition=root    // root
>> a/cpuset.cpus=0-3    // root
>> a/cgroup.procs        // user, they can organize subtree as needed
>>
>> For example the user may want to create a (sub)partition with some of
>> the CPUs they got:
>>
>> user$ mkdir a/b
>>
>> a/b/cpuset.partition=root    // user
>> a/b/cpuset.cpus=0-1        // user
>>
>> This should be a valid configuration and behavior, no?
>
> Thank for the comment. Yes, that can be a valid configuration.
>
> One possible workaround may be to see if the current user has write 
> access to its parent partition root. If so, we can allow it to create 
> a sub-partition, if not, we will forbid it. 

It is not that simple to check if the user can write to its parent. So I 
will put it down as a TODO item, but will still forbid such a 
configuration for now.

Cheers,
Longman