The Administrator's Menu Program
Scott White Wide area networking (WAN) has introduced a new era of computer system administration through remote access. After the initial system installation, WAN technology allows a much higher system-to-administrator ratio. I am a central system administrator for computers scattered across nine states. To increase system productivity and relegate some administration functions, I needed a method to grant certain users at the remote locations, called local administrators, access to limited administration functions. That method would have to be a setuid executable, but what would the interface be? The local administrators, in some cases, are not completely familiar with UNIX. Therefore, a menu-driven interface seemed best for all skill levels. I decided on the following attributes for the interface: 1) reasonable security protection preventing unwanted use 2) script based for quick development and revision 3) easy customization for different users so one could grant varying system administration capabilities 4) reusability, because I was continually rewriting menu-based scripts. With these design parameters, I developed the Administrator's Menuing Program, amp. In short, amp is a dynamically configurable pseudo-system administrator's menuing utility. How amp Works The amp utility has four basic parts. A C program front-end authenticates the user and calls the main script. A menu configuration file which lists all the users and their respective menuing options is supplied for the main script. The main script presents the menu options to the user and executes menu-option scripts when chosen. Finally, there are the menu-option scripts that perform different administration functions. To authenticate the user, the front-end to the menu interface is the setuid C program amp.c (Listing 1). The user executing the program is checked for membership in the group admgrp. This group lists the local administrators as members. The group file entry might look like:
admgrp:*:1000:white,thompson,howard,miller
If the user is verified as being a member of admgrp, the program performs a setuid to zero and makes a system call executing the amp.sh menu interface script. Otherwise, the program advises that the user is not authorized to run the administration menus and exits immediately. Using the admgrp group exclusively for local administrator authentication maintains reasonable security precautions. Additionally, the central administrator can easily remove a local administrator by editing the group file. After compiling amp.c, the amp executable is placed in a directory common to all users' PATH, for instance, /usr/local/bin. The amp executable is given setuid mode and is executable by all (r-sr-xr-x permissions). When a user wishes to run the amp utility, s/he types in amp, then hits Return. The menu configuration file is named ampusers (Listing 2). This file has entries in the form of menu blocks for each user. The format of a user's entry starts with a menu user identifier, usually the user's login name. The following lines each list a menu choice text string, followed by a "~" and then the command string to execute the menu choice. Full pathnames should be used for most commands. The tilde is the field delimiter character and hence cannot be used in either the menu option text string or the command string. A single blank line (no spaces allowed) separates one user entry from another. When the amp utility is executed, the menu choices will be shown exactly as entered and in the same order. The menu choices are divided into menu pages of 10 choices each and can be traversed by pressing "n" for the next page when running the program. The heart of the amp utility is the amp.sh menu script (Listing 3). The syntax for calling this script is "amp.sh identifier" where "identifier" is the first line of a menu block the menu user identifier. This script loads two arrays: MENUTEXT, which contains the menu choice text strings from the configuration file, and MENUPGM, which contains the associated command string to execute. These arrays start at subscript 1. Therefore, the first page of a user menu always starts with menu option number "1" and continues up to option "9"; subsequent menu pages start with option "0." Finally the amp.sh script enters a loop, presenting the menu choices and executing the associated menu choice program until the exit option is selected. The amp utility is designed to be recursive, thereby allowing submenus multiple levels deep (see the miller_1.3 entry in Listing 2). When a submenu is exited, the next level up is presented again. For a submenu, use the user's login name appended with some differentiating text string for the menu user identifier. Basic Administration Scripts The foundation of the menuing system is set with amp.c, amp.sh, and the ampusers files. Now all one has to do is plug the necessary administration scripts for the individual local administrator into the configuration file. A central administrator soon will develop a full repertoire of scripts to handle all types of local administration functions. Since most administration scripts are site dependent, I have included four basic scripts showing what might be done. These scripts perform some of the usual system administration functions: 1) can.sh a standard administration script allowing the user to cancel any print job (Listing 4), 2) grpkill.sh a kill script that limits the user to killing user processes belonging to a certain group (Listing 5), 3) adduser.sh a basic add user script (Listing 6), 4) remuser.sh a basic remove user script (Listing 7). With the system administrator's creativity and the flexibility of shell scripting, the possibilities for other administration scripts are enormous. I have placed the amp.sh script, the ampusers configuration file, and the administration scripts in a common amp directory, /usr/bin/amp. This directory is referenced in amp.sh by the script variable AMPDIR. You will need to change the variable if the ampusers file is stored elsewhere. All the scripts and the directory are owned by root with rwxr-x--- permissions. Extensions and Other Uses With a few changes, the amp.sh script can easily be changed to run any type of dynamically configurable menu interface. A good candidate is a menu presented to the user upon login. In this case, the amp.c front-end would be not be used, because the user would not have to be verified. The amp.sh script and the ampusers configuration file might reside in /usr/bin (make sure to change the AMPDIR script variable in amp.sh). The ampusers file would be edited to contain all users preferring a login menu and their respective login menu options, for instance, a file editor, a debugger, a mail program, and a spreadsheet. The user's .profile or .login file would execute /usr/bin/amp.sh username, in which username references an entry in ampusers. A logical extension is editing amp.sh to reference a configuration file in the user's home directory, thereby providing users with the flexibility to change their own menus. I have found the amp utility very useful in providing local administrators limited access to system administration functions. When a new situation arises that seems appropriate for local administration, I write a shell script and insert it into the local admin's menu section in ampusers. I can just as easily remove access to any administrative function. Because of amp's reusability, I now rarely write menu interface scripts; I simply use the amp.sh script with a different configuration file.
About the Author
Scott White is a graduate of Southern Illinois University with a B.S. in Industrial Technology. In six years in the UNIX and C environments, he has worked on projects with the Pentagon, EDS, GM, McDonnell-Douglas, and a regional Bell company. Currently, he is a computer consultant with CompAid Consulting Services. Although system administration is his specialty, he enjoys programming for the cheap thrill of the creative process. He can be reached via CompuServe at 73004.2401@compuserve.com.
|