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

[Waiman Long <longman@redhat.com>]

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.

Cheers,
Longman