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

[Michal Koutný]

Hi Waiman.

On Mon, Apr 27, 2026 at 11:34:39PM -0400, Waiman Long <longman@xxxxxxxxxx> 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].

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?

Thanks,
Michal


[1] And thanks to the need of cpuset.cpus.exclusive chain down the tree,
    the capability check for remote partitions may be too restrictive
    too. But I don't not plead for its removal now.

Attachment: signature.asc
Description: PGP signature