Does managing cgroups require root access?

Clash Royale CLAN TAG#URR8PPP
up vote
11
down vote
favorite
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.
linux not-root-user privileges cgroups
add a comment |Â
up vote
11
down vote
favorite
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.
linux not-root-user privileges cgroups
1
wiki.archlinux.org/index.php/Cgroups has some info, you'll need some setup by root apparently (haven't looked in detail at cgroups myself yet).
â Mat
Apr 21 '15 at 21:35
That website does not help with the details though. It is just a high level overview.
â Rambo
Apr 22 '15 at 13:53
1
Well, it does tell you that root can setup groups that are manageable by non-root users.
â Mat
Apr 22 '15 at 14:03
I looked into cgroups extensively a while ago; that info may be of use to you. However I was doing it all as root, so I don't have the answer to this particular question.
â Wildcard
Apr 15 '16 at 23:40
You could make a 'editcgroup' group, then allow everyone in that group to do 'sudo cgcreate' and 'sudo cgdelete'
â John Militer
Apr 21 '16 at 3:36
add a comment |Â
up vote
11
down vote
favorite
up vote
11
down vote
favorite
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.
linux not-root-user privileges cgroups
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.
linux not-root-user privileges cgroups
linux not-root-user privileges cgroups
edited Mar 26 '17 at 8:01
user2066657
389110
389110
asked Apr 21 '15 at 19:53
Rambo
764
764
1
wiki.archlinux.org/index.php/Cgroups has some info, you'll need some setup by root apparently (haven't looked in detail at cgroups myself yet).
â Mat
Apr 21 '15 at 21:35
That website does not help with the details though. It is just a high level overview.
â Rambo
Apr 22 '15 at 13:53
1
Well, it does tell you that root can setup groups that are manageable by non-root users.
â Mat
Apr 22 '15 at 14:03
I looked into cgroups extensively a while ago; that info may be of use to you. However I was doing it all as root, so I don't have the answer to this particular question.
â Wildcard
Apr 15 '16 at 23:40
You could make a 'editcgroup' group, then allow everyone in that group to do 'sudo cgcreate' and 'sudo cgdelete'
â John Militer
Apr 21 '16 at 3:36
add a comment |Â
1
wiki.archlinux.org/index.php/Cgroups has some info, you'll need some setup by root apparently (haven't looked in detail at cgroups myself yet).
â Mat
Apr 21 '15 at 21:35
That website does not help with the details though. It is just a high level overview.
â Rambo
Apr 22 '15 at 13:53
1
Well, it does tell you that root can setup groups that are manageable by non-root users.
â Mat
Apr 22 '15 at 14:03
I looked into cgroups extensively a while ago; that info may be of use to you. However I was doing it all as root, so I don't have the answer to this particular question.
â Wildcard
Apr 15 '16 at 23:40
You could make a 'editcgroup' group, then allow everyone in that group to do 'sudo cgcreate' and 'sudo cgdelete'
â John Militer
Apr 21 '16 at 3:36
1
1
wiki.archlinux.org/index.php/Cgroups has some info, you'll need some setup by root apparently (haven't looked in detail at cgroups myself yet).
â Mat
Apr 21 '15 at 21:35
wiki.archlinux.org/index.php/Cgroups has some info, you'll need some setup by root apparently (haven't looked in detail at cgroups myself yet).
â Mat
Apr 21 '15 at 21:35
That website does not help with the details though. It is just a high level overview.
â Rambo
Apr 22 '15 at 13:53
That website does not help with the details though. It is just a high level overview.
â Rambo
Apr 22 '15 at 13:53
1
1
Well, it does tell you that root can setup groups that are manageable by non-root users.
â Mat
Apr 22 '15 at 14:03
Well, it does tell you that root can setup groups that are manageable by non-root users.
â Mat
Apr 22 '15 at 14:03
I looked into cgroups extensively a while ago; that info may be of use to you. However I was doing it all as root, so I don't have the answer to this particular question.
â Wildcard
Apr 15 '16 at 23:40
I looked into cgroups extensively a while ago; that info may be of use to you. However I was doing it all as root, so I don't have the answer to this particular question.
â Wildcard
Apr 15 '16 at 23:40
You could make a 'editcgroup' group, then allow everyone in that group to do 'sudo cgcreate' and 'sudo cgdelete'
â John Militer
Apr 21 '16 at 3:36
You could make a 'editcgroup' group, then allow everyone in that group to do 'sudo cgcreate' and 'sudo cgdelete'
â John Militer
Apr 21 '16 at 3:36
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
2
down vote
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.
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
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.
add a comment |Â
up vote
2
down vote
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.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
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.
answered Sep 22 '15 at 22:37
Gravy
1,338520
1,338520
add a comment |Â
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Sep 22 '15 at 23:07
V13
2,210612
2,210612
add a comment |Â
add a comment |Â
up vote
1
down vote
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
add a comment |Â
up vote
1
down vote
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
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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
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
answered Jun 27 '17 at 18:21
William Sandin
29115
29115
add a comment |Â
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
edited Sep 8 at 5:24
Tejas
1,77621837
1,77621837
answered Sep 7 at 21:21
oceansailor
111
111
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f197718%2fdoes-managing-cgroups-require-root-access%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
wiki.archlinux.org/index.php/Cgroups has some info, you'll need some setup by root apparently (haven't looked in detail at cgroups myself yet).
â Mat
Apr 21 '15 at 21:35
That website does not help with the details though. It is just a high level overview.
â Rambo
Apr 22 '15 at 13:53
1
Well, it does tell you that root can setup groups that are manageable by non-root users.
â Mat
Apr 22 '15 at 14:03
I looked into cgroups extensively a while ago; that info may be of use to you. However I was doing it all as root, so I don't have the answer to this particular question.
â Wildcard
Apr 15 '16 at 23:40
You could make a 'editcgroup' group, then allow everyone in that group to do 'sudo cgcreate' and 'sudo cgdelete'
â John Militer
Apr 21 '16 at 3:36