The sudo utility is one of the workhorses of Linux, but it’s often not used as skillfully as it could be. If you’re just using sudo to provide full root access to regular users, it’s time to take a step back and fine-tune sudo to be a bit more picky.
Way back in the day, many Linux users would just su to root in order to manage packages or do other system tasks. Some folks would even just run as “root,” because it was simpler. That’s a bad habit, one that Ubuntu helped me (and probably a fair number of others) break.
But blindly adding folks to the admin group, or just adding them with ALL privileges, is a pretty bad habit as well. If you’re the only user on your system, giving the classic ALL may be fine, but if you’re sharing a system at home or setting up a system for multiple users, being more fine-grained with sudo is a better idea.
Fine-Tuning Sudo
To fine-tune sudo, we’re going to start by editing the sudoers file. That’s usually /etc/sudoers. To edit this, you don’t open sudoers in your editor, normally – you’re going to use the visudo program. It will open the sudoers file in the default editor, but you can’t just open the file in Gedit or whatnot. You also need to be root or use sudo, which is a little recursive, but OK.
The default settings for the sudoers file vary depending on which distribution you’re using. I’m using a Linux Mint system for the purposes of this piece, so if you’re using Fedora, openSUSE, or another distro it probably will be different.
Let’s take a look at a few of the lines from the sudoers file:
# User privilege specification root ALL=(ALL:ALL) ALL # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL
Basically, this is allowing root to do anything with sudo, and granting members of the admin group and sudo groups pretty much unlimited power. This works on single user systems or for very small shops, perhaps, but not so well when you have a lot of admins and users who might need some elevated privileges but not all.
Let’s say that you want to let a user do something that would require elevated privileges, but without giving run of the system. For example, what if you want to let a user run apt-get update and apt-get upgrade?
zonker ALL=(root) /usr/bin/apt-get
Let’s break this down. The first field is the username, in this case “zonker.” Obviously, you want to replace this with the desired username. The next field is the hostname. In this case, I’m allowing “ALL” though you can restrict to localhost or something else if you prefer. This is for more complex situations, and I’ll cover this in a future tutorial.
The next field (root) is the user that will execute the command. This doesn’t have to be root, by the way. You might want to give a user the ability to execute a command as another user in a lot of situations, for instance when a process runs as a different user than root.
Finally, the command you want to run. The full path is needed there, so use /usr/bin/apt-get instead of just apt-get. Note that you don’t need to type the full command name when you’re using sudo.
More Than One Command
What if you want to give permission to use more than one command? You can do that in a couple of ways. If it’s just one user and a couple of commands, you can just separate them with a comma, like so:
zonker ALL=(root) /usr/bin/apt-get, /usr/bin/dpkg
Now zonker can run apt-get or dpkg. One thing to note, even if you can run a command as a normal user, you can’t use it with sudo unless you’re explicitly allowed to do so. For instance, even normal users can run dpkg -l to see what packages are installed. But you can’t use it with sudo if you’re not allowed to use dpkg, because you’d be running it with elevated privileges.
You can also produce aliases with a set of commands, so you can provide an alias instead of a list of commands. Since you have to generate the list of commands anyway, what’s the advantage here? Well, if you have a complex setup, you might want to give different groups different sets of commands. For instance, say you have a group for admins, and a group for Web developers. You might want to only give developers the ability to restart Apache, but admins should be able to restart Apache or shut down or reboot the machine. Here you have two aliases:
Cmnd_Alias SHUTDOWN= /sbin/shutdown, sbin/reboot, /sbin/halt Cmnd_Alias APACHE= /etc/init.d/apache2
Now you apply them, like so:
ADMINS ALL= SHUTDOWN, APACHE WEB ALL= APACHE
This is shown a bit differently on the Ubuntu community wiki.
Note that you should spend some time verifying any changes. You don’t want to leave users in a lurch, or give them more power than intended.
This has been a pretty quick overview, but it ought to help you get started in fine-tuning sudo. Pretty soon, I’ll follow up and cover how you can configure more complex setups with user aliases and multiple hosts. Until then, happy sudo’ing.
