By Hans-Georg Eßer
Linux is a multiple user system, and access to the privileged root account is well-protected on many machines. Normal user privileges are typically insufficient to mount a CD or hot-plug a memory stick. Some distributions even require root privileges for Internet access.
If the main user is also the administrator, which is quite normal for privately owned PCs, you can just type su and enter the root password to assume the required privileges - but once you have assumed these privileges with su, all subsequent commands will have the power of root, as if you are simply working under the root account: small typos can have a devastating effect.
One solution to this problem is a scenario in which a user can assume only a narrower set of root-level privileges specified by the administrator. For instance, a user may be allowed to assume the power to mount a USB stick without having access to other types of root-level commands.
The legacy sudo tool is the traditional means for assigning administrative privileges to a user without giving the user the root password, but an alternative tool called Op makes this process easier for both the administrator and the user.
The sudo command [2] gives you a legacy approach to the problem of letting normal users run a set of root-level commands specified by the administrator.
Some Linux distributions (for example, Ubuntu and Knoppix) use sudo today to make the standard user the administrator, adding an entry of the form username ALL = (root) ALL to the /etc/sudoers configuration file.
In this case, any user can run arbitrary commands as root by typing the sudo keyword in front of the command syntax; for example, the command sudo killall -9 command kills all processes called command. When you enter a command like this, sudo asks you for your own password before launching commands with root privileges.
If you prefer a more granular approach to specifying who is allowed to run which commands, sudo can help. Imagine you want to grant a user called abc the right to run the command tail -f /var/log/messages; just add the following line to the /etc/sudoers file:
abc ALL = (root) /usr/bin/tail -f /var/log/messages
Of course, the user will need to type the command exactly as it is shown here, although sudo will not object if the command contains a few blanks. But if you were to leave out the -f parameter, or change the order, you would see the following error message:
[abc@kira ~]$ sudo /usr/bin/tail/var/log/messages -f Sorry, user abc is not allowed to execute '/usr/bin/tail /var/log/ messages -f' as root on kira.
With proper syntax, there are no complaints:
[abc@kira ~]$ sudo /usr/bin/tail-f /var/log/messages Mar 31 14:13:39 kira -- MARK -- Mar 31 14:33:39 kira -- MARK -- [...]
Users with sudo privileges must remember the precise syntax of any commands they are authorized to run - or they could run sudo -l to check their options:
[abc@kira ~]$ sudo -l User abc may run the following commands on this host: (root) /usr/bin/tail -f /var/log/messages
Each incorrect sudo call generates a log entry, and on some machines, sudo will even mail the system administrator.
The Op tool is a little known sudo replacement with the added benefit of simpler configuration and a more intuitive approach to running commands.
A one-liner is all you need for simple commands: the general syntax of an Op config file entry is as follows:
command_shortcut command; options
For example, if you want to allow the user abc to shutdown a machine by running the halt command, the following line would do the trick:
halt /sbin/halt; users=abc
If you would prefer the user to type his own password to authorize the command (following the traditional sudo approach), just add the password option to the line:
halt /sbin/halt; users=abc password
This lets you configure Op for critical tasks in a matter of minutes. Note that you need to specify the full path to the commands in question (for instance, /sbin/halt rather than just halt in our example). The user abc can then type op halt in the shell to shutdown the PC.
You can follow standard procedures for the Op build; but don't forget to pass these two options on to configure:
./configure --prefix=/usr --sysconfdir=/etc make make install
Without the prefix option, the program will install below /usr/local/; and if you leave out the --sysconfdir option, it will look for configuration files in $PREFIX/etc/.
We had no trouble installing the current version (1.32) of Op on a Suse Linux 9.3 machine in our lab; on Debian Sarge we needed to apt-get install flex before running make.
Type mkdir -p /etc/op.d to create a configuration directory for Op, then create a sample /etc/op.d/log.conf file, as shown in Listing 1, and give the command chmod 600 /etc/op.d/log.conf to modify the privileges. Read and write access to this file is restricted to the root user. If you forget to run chmod, the program will not work (and it will additionally display a confusing error message stating that it can't find the configuration file).
The two lines in Listing 1 create two new command shortcuts, messages and syslog, allowing the user abc to access the two logfiles by running the op messages and op syslog commands. The Listing specifies the full path for cat, /bin/cat, as Op will not be able to find the utility if you do not provide the full path.
| Listing 1: Getting Started with Op |
01 messages /bin/cat /var/log/messages; users=abc 02 syslog /bin/cat /var/log/syslog; users=abc |
One of Op's most useful features is the ability to add shell scripts to the configuration file. Listing 2 shows an example that defines the Op command, log, which in turn allows authorized users to read the /var/log/messages and /var/log/syslog files. Scripts can parse and evaluate arguments; like normal scripts, they use the $1, $2, etc. environmental variables to do this. The second command shortcut in Listing 2, apache, allows a user to start and stop Apache services. The script for the command shortcut log defines the $TERM variable to allow the less command to work.
| Listing 2: Starting and Stopping Apache |
01 log /bin/sh -c ' 02 export TERM=xterm 03 case $1 in 04 messages) less /var/log/messages ;; 05 syslog) less /var/log/syslog ;; 06 *) echo "op: You are not allowed to read the logfile \'$1\' " ;; 07 esac 08 '; 09 users=abc 10 help="View logfiles (messages and syslog only)" 11 12 apache /bin/sh -c ' 13 case $1 in 14 start|stop) /etc/init.d/apache $1 ;; 15 *) echo "op: apache only understands start and stop" ;; 16 esac 17 '; 18 users=abc 19 help="Start and stop the Apache server" |
Store the new command definitions in files below /etc/op.d/ (again, read access must be restricted to root only); as an alternative, you can store all your definitions in a single file.
Op's -l flag shows you the command shortcuts you can run - the program hides command shortcuts for other users. The script catches input errors and tells users that they can only view the messages and syslog logfiles:
abc@amd64:~> op -l apache Start and stop Apache log View logfiles (messagesand syslog only) abc@amd64:~> op log security op: You are not allowed to view the 'security' logfile
Op scripts are one advantage that Op has over sudo: to achieve the same results with the legacy tool, you would need to write a script, store it on the filesystem (for example, in /usr/local/bin), and then allow users to call the script in /etc/sudoers. In case of changes, you would need to modify both the script and the sudo configuration file.
It is easy to verify the fact that Op only lets the users specified in users= run privileged commands; to do so, run the command working as nobody:
amd64:# su - nobody nobody@amd64:~> op -l nobody@amd64:~> op log messages log: permission denied by op
The list of permitted Op commands for nobody is empty, and the tool issues a warning when nobody tries to view the logfiles, generating an entry in the /var/log/auth.log logfile or /var/log/messages:
Feb 8 14:56:52 amd64 op[4716]: nobody log messages: Both user, group and netgroup authentication failed
Just like sudo, Op can group multiple users, and then grant or revoke group privileges. Let's assume you have three users, abc, def, and ghi, who you want to perform various system tasks; you can add these users to an ADMINS group with an entry such as the following:
ADMINS=(abc|def|ghi)
For all command shortcuts that you want to assign to these users, just specify users=ADMINS. If you need to add a fourth administrator, jkl, to the group, or define a new command for the group later, you just have to change one line in the config file.
Op can manage multiple machines (by reference to the machine names), allowing administrators to configure the behavior of several computers in a central Op configuration file.
Op has a particularly flexible approach to passing environmental variables to programs launched with root privileges. If you do not specify any other parameters, Op deletes all environmental variables before running a command.
The environment option prevents this and passes all variables in. As an alternative, you can manually specify a set of variables you want to keep by adding their name entries in the form of $Name (with a leading dollar sign). Listing 3 gives an example of using variables.
The test command shortcut simply calls the env program, which outputs a list of all environmental variables.
| Listing 3: Op with Variables |
01 test /usr/bin/env; 02 users=abc 03 $LANG $TERM $SHELL $PATH |
Op is a powerful tool with similar functionality to sudo, but with simpler configuration and more intuitive commands that make life easier for the administrator and the user - even if they happen to be the same person.
| INFO |
|
[1] Op homepage: http://svn.swapoff.org/op/
[2] Sudo homepage: http://www.sudo.ws/sudo/ |