Setting up sudo, part 2

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

into this:

User_Alias	OPS = jesse, vail, rafael
Cmnd_Alias	CONTROL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot

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:


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, \

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.

See Setting up Sudo, part 1

Insider: How the basic tech behind the Internet works
Join the discussion
Be the first to comment on this article. Our Commenting Policies