Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

IS there an ideal way to limit access to server admins as to what they can and can not do with sudo? I would like to have levels of access from basic command line actions to more advanced abilities such as service control. I also do not want them having the ability to touch root or edit logs.

I'm running CentOS 6 with CPanel on the boxes.

share|improve this question
What do this have to do with SSH access and control? – Ram Jun 14 '12 at 0:28
up vote 2 down vote accepted

You could use command aliases to permit, or forbid such actions, for instance:

Cmnd_Alias OPS  = /usr/sbin/shutdown,\

%dev        ALL = (ALL:ALL) ALL, !OPS

Basically, %dev means anyone part of the dev group, can do anything, as any user, EXCEPT OPS which provides a list of commands you do not wish them to run as sudo.

Alternatively you can create your own Cmnd_Alias and do %dev ALL=OPS to permit the use of only the listed operations.

share|improve this answer
I personally think this is the best answer yet. – Lucas Kauffman Jun 14 '12 at 8:49

You can define separate allowed sudo commands per user. For instance instead of giving them all commands we can give a certain user called testing the permission to restart the webserver with sudo:

testing ALL=/etc/init.d/httpd restart

(this should be in your sudoers file)

share|improve this answer

Besides sudo, you can write scripts to do things with suid bit set (not necessarily suid root, maybe suid www-data or even suid nobody) and group execute bit set, and allow people to run it by adding them to the appropriate group that owns the script in question.

sudo is better, because it leaves a verbose audit trail and can be quite flexible, though the sudoers(5) man page is rather human-unfriendly and full of Backus-Naur spaghetti. And sudo tends to throw up and stop working on any syntax error in /etc/sudoers, so you'd better set yourself a real root password for the time you set up sudoers file, or you may find yourself locked out with broken sudo.

sudo or not sudo, be very careful when designing scripts, parsing command line arguments, writing to admin-controllable files.

One example, let's imagine you have a script that gets invoked under a privileged account (root or whatever), and by the way it writes with truncation (>) to a file that your admin can replace with a symlink pointing somewhere you never thought of.

Another example, editing /etc/network/interfaces (or an analog of it in your distro) and then ifup'ing an interface may seem innocent, but there are pre/post-up/down scripts that are invoked as root. Oops.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.