Does managing cgroups require root access?

Question

I am trying to work with control groups on two different operating systems (Ubuntu and CentOS). There are few concerns that I would like to ask.

I am trying to create a control group using the cgcreate command, and it looks like it requires root access on the machine. All the examples that I have seen so far do not say anything about needing to be the root user for creating or modifying control groups.

Is it really necessary to be the root user? The end goal is to write a C++ application that creates and manages control groups to control resources using the libcgroup API. But the C++ application is not going to be run by any root user. It could be any normal user.

Answer 1

The normal scenario is that you set cgcreate, cgset, cgdelete, cgget, etc. up as root. Eventually the program/script meant to be restrained from sucking to many resources will be executed as a normal user. So, setup as root, use and execution as user.

This is being done with the -a and -t parameters of the cgcreate command (executed as root). So already when you set a group up. In my case:

cgcreate -t monero:monero -a monero:monero -g memory,cpu:monerogroup

where monero is the username of the future user who will execute and run the program with the cgroup restrictions. For the fine difference between the -a and -t subparameters refer to the man pages of cgcreate.

man cgcreate

In most cases that is both the same user.

Then, set up the restrictions (still as root):

cgset -r memory.limit_in_bytes=$((4*1024*1024*1024)) monerogroup

cgset -r cpu.shares=128 monerogroup

Check your entries if you want to:

cgget -g memory:/monerogroup | grep bytes

And then eventually switch user, in my case user monero, and from the right folder:

cgexec -g memory,cpu:monerogroup ./monerod

The user won't have any difficulty with permissions or so as you set it up specifically for him.

Answer 2

Security implications of this aside, you can set the setuid bit

chmod +s /bin/cgcreate
chmod +s /bin/cgdelete

to give non root users that run that program root power.

The recomendation would be to then remove normal user access

chmod 550 /bin/cgcreate
chmod 550 /bin/cgdelete

and create a special group that you wish to allow to use cgcreate IE cgusers,

groupadd cgusers

and change the group membership on those files to that group:

chgrp cgusers /bin/cgcreate
chgrp cgusers /bin/cgdelete

All of that would be run by root, after that all users in the cgusers group, will run cgcreate and cgdelete as root instead of as themselves. You would just need to have members you'd want to have this power under the right group.

Answer 3

Cgroups are ultimately handled via the cgroup filesystem(s). The ability to create cgroups should merely be the ability to create directories under that/them and write to files. If you mount the cgroup FSs with more elaborate permissions, or if you change their permissions on the fly, then certain users should be able to do stuff. Obviously you won't be able to add the process IDs of other users' process to the tasks file. You'll only be able to add your user's.

Having said that, I'm not sure the above is global. I.e. there's a chance that certain cgroups don't support this.

Overall, the best approach is to use a cgroup manager which can then be instructed to associate tasks to a cgroup. I believe that cgmanager does something like this.

Answer 4

Short answer is no.

For creation, and ownership assignment of a cgroup, you depend on root privileges. There is no reliable way to get around it.

However, you can create a cgroup and assign ownership to a certain user or group.

User

$ u=$(whoami)
$ sudo mkdir /sys/fs/cgroup/cpuset/${u}
$ sudo chown -R ${u}: /sys/fs/cgroup/cpuset/${u}

Group

$ g=MYGROUP && grep ^${g}: /etc/group || echo "Your group doesn't exist. Run \"mkgroup $g\" and repeat this command before you continue." 
$ sudo mkdir /sys/fs/cgroup/cpuset/${g}
$ sudo chgrp -R ${g} /sys/fs/cgroup/cpuset/${g}