If when setting up your sudoers file using the visudo command, you define a group of users and a group of commands, you can assign the command set to the use set without having to add a separate line for each user. Over the long haul, this might save you a lot of work. You could turn something that looks like this repetitive list of users and the commands they are allowed to run as root:
jesse ALL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot vail ALL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot rafael ALL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot
User_Alias OPS = jesse, vail, rafael Cmnd_Alias CONTROL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot OPS ALL = OPS
Of course, that isn't convincingly better unless you have a lot more lines in your file and a number of users who share the same set of responsibilities. For example, you might want to assign a certain set of commands to your system administrators, another to your developers and a third set to your technical support staff.
An out-of-the-box sudoers file will generally only contain some comments detailing where each type of alias is supposed to be defined and maybe one "root ALL=(ALL) ALL" command that allows root to run any command using sudo. The fleshed out, customized file may be hundreds of lines long with both privilege settings and explanations about what was intended. User aliases, as the above example illustrates, contain the keyword "User_Alias" as the first item on the line and are then followed by the alias name ("OPS" in the above example) and the list of commands. Notice that full paths are specified with each command. We don't want just any command by that name that might appear on the system to be run with the authority of root.
# User alias specification User_Alias SYSADMINS=shs,jdoe,allan User_Alias DEVELOPERS=chris,peter,martha,sally User_Alias WEBMASTERS=amy,sbob
Runas specifications determine the user or group that a command can be run as. For example, if we put the line "shs boson = (fred) /usr/bin/touch", then the user shs can issue the touch command as fred on boson. If we want to group runas users into an alias, we can do this:
Runas_Alias DB = oracle, postgres
The following line would then allow the user sbob to run any command on any system as oracle or postgres:
sbob ALL = (DB) ALL
You can group systems together in a Host-Alias in a similar manner. Just use the Host_Alias keyword, provide a name for your system grouping and then list the group members.
Host_Alias DEVBOXES = mercury, venus, earth, mars, jupiter, saturn, uranus, neptune
Then, if you want sbob to have database privileges on only the development servers, you can use this command:
sbob DEVBOXES = (DB) ALL
Command aliases are defined with the keyword Cmnd_Alias, the name and a list of commands. These should be added in logical groupings. For example, this alias makes a lot of sense since it groups the commands that deal with passwords and other user parameters:
Cmnd_Alias VIPW = /usr/sbin/vipw, /usr/bin/passwd, /usr/bin/chsh, \ /usr/bin/chfn
Also notice how the continuation character allows alias definitions to spans lines.
User specifications can begin with a specific user name (e.g., shs), an alias (e.g., OPS), a netgroup (e.g., +netmgrs) or system group (e.g., %wheel). For example:
+netmgrs DEPTBOXES = ALL
Once you define a set of aliases that works for your site, you will find that maintaining the sudoers file becomes much easier, especially when many users and systems are involved.
The sudoers file also includes a section that is intended to allow sudo defaults to be changed. For example, you might decide not to lecture (i.e., forgo displaying a short blurb about the use of xxxxx) or can specify a file containing an alternate lecture. The sample command below tells sudo not to lecture the developers (anyone included in the DEVELOPERS user alias).
# Defaults specification Defaults:DEVELOPERS !lecture
The sudoers file can become fairly complicated, but if you set it up carefully, it can provide a reliable degree of control over who does what on your servers. Just remember to update it as people come and go and change positions. It's an easy thing to overlook if you set it up and then forget about it.
This article is published as part of the IDG Contributor Network. Want to Join?