1

I've been playing with cset to set cpu affinity for running processes. I'm recreating the built-in "shield" function manually with set and proc, to add some subsets for specific threads of my application. I have a bash script that is calling cset to create the sets, and move the correct threads to the correct sets. It works when run with sudo.

Now I'd like to make this script executable by another user, who does not have sudo powers. I trust this user enough to be responsible with cset, but don't want to open up the wide powers of root.

I thought that CAP_SYS_NICE -- which is needed for sched_setaffinity, which I just assume cset must use -- on the script would be sufficient, but that didn't work. I tried extending CAP_SYS_NICE to the cset program (which is a thin python wrapper for the cset python library). No dice. The output of cap_to_text on my CAP_SYS_NICE'd scripts is "=cap_ipc_lock,cap_sys_nice,cap_sys_resource+eip" (it has ipc_lock and sys_resource for other reasons; I think only sys_nice is relevant).

Any ideas?

Improve this question
2
  • Quick thing... Which distribution is this?
    – ewwhite
    Jun 20, 2012 at 3:58
  • @ewwhite I'm using RHEL 6.2. In case anyone else would like to know, it's cset v1.5.6, but I could change that.
    – RaveTheTadpole
    Jun 21, 2012 at 3:42

3 Answers 3

Reset to default
1

Rather just give that user restricted sudo permission to only run that script, for example:

bob ALL=(root) NOPASSWD: /usr/local/bin/cset.sh

Remove NOPASSWD: if you want the user to authenticate with their password.

Improve this answer
1
  • Thanks, that makes a lot of sense. I had forgotten that this limited sudo was possible. (Can you tell I don't do much sysadmin work?) And thanks for the example.
    – RaveTheTadpole
    Jun 21, 2012 at 16:03
1

I always thought of cset as a SuSE tool. I used it on RHEL back in EL5, but with EL6, cgroups are the preferred method to handle shielding.

I'd probably go the sudo route, limiting access to the specific commands needed to place your users' processes into the shield.

Improve this answer
1
  • +1 for cgroups. I didn't know they existed, and they do look to be the preferred method in RHEL 6. RH provides documentation in their "Resource Management Guide". As for the "as non-root" aspect, I'm going to green checkmark mgorven who came up with it first and with more detail.
    – RaveTheTadpole
    Jun 21, 2012 at 15:58
1

While cgroups seems to supercede cset/cpusets (as ewwhite said), I went ahead with the old method anyway because it was more familiar and still works.

For the permission issue, my particular problem was solved by first using cset to create a tree inside /cpusets with which I sudo chown -R root:myusergroup /cpusets/mytree and sudo chmod -R g+rwX /cpusets/mytree. After that, users in myusergroup are able to move processes around inside the tree by echo $MYPID >> /cpusets/mytree/subtree/tasks. Unfortunately cset doesn't seem to work without full permission on all of /cpusets -- I believe it tries to reread the entire /cpusets directory every time you run a command -- so I had to resort to this manual method of moving processes.

I'm not saying it's the ideal solution for everyone, but it worked best with my background and situation.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .