Does managing cgroups require root access?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
11
down vote

favorite
2












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.










share|improve this question



















  • 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














up vote
11
down vote

favorite
2












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.










share|improve this question



















  • 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












up vote
11
down vote

favorite
2









up vote
11
down vote

favorite
2






2





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.










share|improve this 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.







linux not-root-user privileges cgroups






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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












  • 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










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.






share|improve this answer



























    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.






    share|improve this answer



























      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





      share|improve this answer



























        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.






        share|improve this answer






















          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













           

          draft saved


          draft discarded


















          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






























          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.






          share|improve this answer
























            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.






            share|improve this answer






















              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.






              share|improve this answer












              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Sep 22 '15 at 22:37









              Gravy

              1,338520




              1,338520






















                  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.






                  share|improve this answer
























                    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.






                    share|improve this answer






















                      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.






                      share|improve this answer












                      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.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Sep 22 '15 at 23:07









                      V13

                      2,210612




                      2,210612




















                          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





                          share|improve this answer
























                            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





                            share|improve this answer






















                              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





                              share|improve this answer












                              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






                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Jun 27 '17 at 18:21









                              William Sandin

                              29115




                              29115




















                                  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.






                                  share|improve this answer


























                                    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.






                                    share|improve this answer
























                                      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.






                                      share|improve this answer














                                      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.







                                      share|improve this answer














                                      share|improve this answer



                                      share|improve this answer








                                      edited Sep 8 at 5:24









                                      Tejas

                                      1,77621837




                                      1,77621837










                                      answered Sep 7 at 21:21









                                      oceansailor

                                      111




                                      111



























                                           

                                          draft saved


                                          draft discarded















































                                           


                                          draft saved


                                          draft discarded














                                          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













































































                                          Popular posts from this blog

                                          Peggy Mitchell

                                          Palaiologos

                                          The Forum (Inglewood, California)