Human - Managing User Accounts with a Friendly Interface

Luca Salvadori

Managing users is a difficult task, as any experienced sys admin may confirm. The work is not so hard, but many tricks must be applied to avoid security breaches or user complaints. If your organization numbers more than 30 users, this task may rapidly become a nightmare and limit your valuable time for other, more demanding tasks. Thus, it is a good idea to delegate someone else to do the job: but how can you be sure that this person performs the job correctly? Be a HUMAN (i.e., an Happy User MANager) by using this simple tool.

Basic Requirements

I needed a simple, easily modified, friendly user interface that would work on any UNIX system. For the first requirements, shell programming was the logical choice (bash in my case), but for the latter, some problems arose because I wanted the tool to be used effectively from everywhere. Thus, I selected dialog, a fine utility distributed under GNU Public License allowing a character terminal to be managed graphically with cursors and masks. For Linuxers, dialog is not new, since most distributions (notably Slackware) use it for installation and setup scripts. The basic architecture of my tool was therefore defined: a collection of subroutines, using standard commands, interfaced to a "dummy" user via simple screens. Now, it was only a matter of coding it.

Features

A good sys admin must create, enable, disable, delete, and modify user accounts. Furthermore, he or she must be able to watch their properties and characteristics. Finally, in order to have more information at hand than the scarce amount stored in a basic /etc/passwd file, it's better to have some kind of database in which to store it. This has been done in two passwd-like files (automatically created at first invocation), passwd.addr in which user's address and phone number is stored, and passwd.subs with account characteristics (expiration date, duration, a.s.o.). The latter file is a nice albeit minor feature to have for my company, since it's actually used only for remote, "nomadic" users logging in through phone lines and PPP, but may also be useful for BBS sysops or small Internet providers. Thus, I customized this part for them even in terminology, just in case. The work is not complete in this part, but I leave that to the relevant people. All passwd-like files are linked through username as a common field and are managed in parallel.

Code and Functionality

The basic script structure is straightforward. After an initialization section in which shell variables are set and local customization is applied, there is a subroutine section, in which all activities are defined. Localization is easy and extensible, since the main passwd file is user-defined and may reflect any UNIX dialect. Extending functionality to NIS-based systems is quite simple, because it's only a matter of changing the basic passwd file and adding a make in the relevant subroutines (makeuser, killuser, lockuser, unlockuser). Finally, a main (relatively simple) program section does the real job, looping on itself until an "exit" option is selected.

When the program is invoked, a main menu is displayed with all available options. Operators may move the cursor to the relevant one and select it with the Return key: a "help" function is present, displaying HUMAN's man page without exiting the procedure.

Next, I'll discuss what the user sees. The first function is SHOW user's characteristics. A simple parsing is performed on the passwd file, and all registered users are displayed for selection. Selections are made by moving cursor onto the selection and pressing the spacebar. Another passwd-like (passwd.excl) file may be added to prevent some particular users from being displayed in all menus: this is useful for system accounts (root, sys, bin, lp, etc.) that must exist on the system but don't need maintenance or have to be removed at any time. After one or more users is selected, a screen is presented for each with all information taken from all passwd* files. An interesting feature is the "Status" field, which shows if the user may or not login following an Enable/Disable action (see below).

Another choice from the main menu, is the NEW function, for creating new accounts. The operator is asked for a username (an error is shown in case it already exists) and other information, including address, phone, etc. in order to fully qualify the user. The username is assigned a password identical to username and is locked for better security, then homedir and skel files (.login, .profile, etc.) are created.

Once a user account is created, you can MODIFY, KILL, LOCK, UNLOCK, ACTIVATE, and DEACTIVATE the user with respect to service subscription. Locking is performed by simply putting an * at the beginning of password field in main passwd. Extending functionality is only matter of fantasy and need: for any detail on functions you may refer to the man page. The Human program and man page can be found at: ftp.mfi.com in /pub/sysadmin.

Security and Installation Tips

If you are handing these tasks over to an unskilled person, some precautions must be taken concerning security and the operator's environment.

In the initialization section, you will find a variable called TRUSTEDUSER. This must be changed with the person's username, which must be a privileged one (i.e., member of wheel group for example). To have this person doing only the tasks included in HUMAN menu, you must keep this account "captive" by changing (by hand) the default shell in main passwd file to HUMAN fully qualified filename (i.e., fullpath/human). Then, change the file protection (to 700) and ownership (to selected username) of all HUMAN files. This will allow the program to be run ONLY by the people you intend it to.

In this way, HUMAN is invoked at login and shell exits with it. To avoid any signal to kill HUMAN inadvertently and leave the user at a shell prompt, I trapped signals 0, 1, 2, 3, 15 to an exit routine, which also deletes any scratch file. These tricks should allow the safe use of the tool, but, as a disclaimer, the person delegated to use it must nevertheless be able to understand what he or she is actually doing.

About the Author

Luca Salvadori is head of the Information Systems Department at LABEN S.p.A., a leading European Space Electronics supplier. His experience spans PDP-11 (whose manuals taught him English) to Linux, Windows, PCs, and networking. He manages the company's Web site (http://www.laben.it/) as well as (in his free time with a bunch of friends) another Linux box (http://aeroweb.lucia.it/) dedicated to aviation. As a hobby, he flies sport aerobatics. Luca can be reached at: lsalvadori@batman.laben.it.