The Administrator's Menu Program
Wide area networking (WAN) has introduced a new era
of computer system
administration through remote access. After the initial
installation, WAN technology allows a much higher
system-to-administrator ratio. I am a central system
computers scattered across nine states. To increase
and relegate some administration functions, I needed
a method to grant
certain users at the remote locations, called local
access to limited administration functions. That method
would have to be
a setuid executable, but what would the interface be?
administrators, in some cases, are not completely familiar
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
2) script based for quick development and revision
3) easy customization for different users so one could
system administration capabilities
4) reusability, because I was continually rewriting
With these design parameters, I developed the Administrator's
Program, amp. In short, amp is a dynamically configurable
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
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.
are the menu-option scripts that perform different administration
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
If the user is verified as being a member of admgrp,
performs a setuid to zero and makes a system call executing
menu interface script. Otherwise, the program advises
that the user is
not authorized to run the administration menus and exits
Using the admgrp group exclusively for local administrator
authentication maintains reasonable security precautions.
the central administrator can easily remove a local
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.
executable is given setuid mode and is executable by
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
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 heart of the amp utility is the amp.sh menu script
(Listing 3). The
syntax for calling this script is "amp.sh identifier"
is the first line of a menu block the menu user identifier.
loads two arrays: MENUTEXT, which contains the menu
choice text strings
from the configuration file, and MENUPGM, which contains
command string to execute. These arrays start at subscript
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
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
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
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.
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
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
scripting, the possibilities for other administration
I have placed the amp.sh script, the ampusers configuration
the administration scripts in a common amp directory,
directory is referenced in amp.sh by the script variable
will need to change the variable if the ampusers file
elsewhere. All the scripts and the directory are owned
by root with
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
menu and their respective login menu options, for instance,
editor, a debugger, a mail program, and a spreadsheet.
.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
thereby providing users with the flexibility to change
their own menus.
I have found the amp utility very useful in providing
administrators limited access to system administration
functions. When a
new situation arises that seems appropriate for local
write a shell script and insert it into the local admin's
in ampusers. I can just as easily remove access to any
function. Because of amp's reusability, I now rarely
interface scripts; I simply use the amp.sh script with
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
CompAid Consulting Services. Although system administration
specialty, he enjoys programming for the cheap thrill
of the creative
process. He can be reached via CompuServe at firstname.lastname@example.org.