NAME
SYNOPSIS
DESCRIPTION
OPERATION
MODES OF OPERATION
OPTIONS
REALMS
FILE
SEE ALSO
DIAGNOSTICS
BUGS
|
|
validate_user − provides user validation for scripts |
|
|
validate_user: -h validate_user: <-V|-C> [options] <password file>
<realm> validate_user: <-A|-D> [options] <password file> |
|
|
validate_user fills a specialized nitch in the broader scope of
password controlled access. It allows password control over execution of
scripts independent of the session the scripts are executed within. It does
this by opening an independent connection to the interactive user’s
controlling terminal and requesting userid and password information. User id
and password pairs are contained in a separate password file from the system
accounts and are segregated into groups called ‘realms’ [see
below]. Why is this needed? Industrial applications often use insecure accounts to give non-supervisory and/or temporary workers access to the computer system. Some of the functions available must be available to all workers, whereas others must be performed only by qualified personal. Without the ability to password protect individual actions being run in an insecure and limited session, supervisory passwords end up being shared improperly and damage to company data by unqualified results with no means of tracing the cause. For example, DNC controlled machine tools usually provide a means to save programs on a central system. Unrestricted access is required in order to load programs into the machines, but only qualified access should be allowed to save programs in the central repository. |
|
|
In all modes of operation, validate_user opens a connection to /dev/tty
to communicate with the user. In both user modes [-V and -C], the password
file is accessed minimally. In both administrative modes [-A and -D], the
password file is locked for the duration of the session. The password file is a ASCII file of new-line terminated records of colon separated fields. The format of each record is ‘userid:realm:password:pw_admin’, where |
|
|
userid is the user id of the user. realm is the realm for which the record is valid. password is the encrypted form of the password, as used in /etc/password
or whatever shadow password setup you system uses. pw_admin is either Y or N determining if the associated userid is a password administrator for the associated realm. Note: if realm is ‘*’, the user is a general password administrator and may add and delete users from all realms. |
|
|
The password file and the directory it resides must satisfy several tests: |
|
|
Ownership and group must match the effective user id and group id of the validate_user
process. Permission bits must be 600 and 700 for the password file and its
directory, respectively. Neither the password file nor its directory may be a symbolic link nor may
the hard link count be greater than one (1) for either. The password file must be a regular file and its directory must be a directory. |
|
|
WARNING: validate_user is a set-uid program. It does not need to be installed as root and should not be. While I have taken pains to avoid buffer overflows and do some careful testing, I am rusty on writing set-uid programs, so use at your own risk and send me any improvements you think it needs. |
|
|
validate_user [options] -V <password file> <realm> − validates a user. The program requests the user’s userid and password. If the value of <realm> is not ‘*’, then it looks for the tuple (userid, password, realm) in <password file>. If found it prints ‘OK’ and exits with a conventional success exit code. Otherwise it prints ’NG’ and terminates with exit value of 1. If the ‘realm’ value is ‘*’, then it looks for the tuple (userid, password) for any realm. If found, it prints ‘OK’, else ‘NG’, as before. |
|
|
validate_user [options] -C <password file> <realm> − allows a user to change his/her password. The program request the user’s userid and password. It then requests the new password twice so as to assure that the blind typing enters the same string. If <realm> is ‘*’, then the user’s password is changed for all realms in the password file. Otherwise, only the password for the single matching realm is changed. |
|
|
validate_user [options] -A <password file> − allows a password file administrator to add users. The program asks for the user’s userid and password and for the realm to which to add users. If the user has a valid entry for either the matching realm or realm = ‘*’ for which pw_admin is ‘Y’, then he may add users. The program then repeatedly requests user id’s, password [with repetition], and password administrator privilege information. A null userid terminates the program. |
|
|
The password file is locked during this entire session, so password administrators must be aware that their actions may interfere with validating users. |
|
|
validate_user [options] -D <password file> − allows a password file administrator to delete users. The program acts similarly to when run with the -A option. The password file is locked during this entire session, so the administrator must be aware that users will not be validated during this session. |
|
|
-V − Validate mode |
|
|
-C − Change Mode |
|
|
-A − Password Add Mode |
|
|
-D − Password Delete Mode |
|
|
-v − increment verbosity - don’t use - was used for debugging |
|
|
-Y <ok symbol> − what to say when user validated [OK] |
|
|
-N <ng symbol> − what to say when user is invalid [NG] |
|
|
-U <name prompt> − prompt to use for name query [Name: ] |
|
|
-P <password prompt> − [Password: ] |
|
|
-O <old password prompt> − [Old Password: ] |
|
|
-R <replacement password prompt> − [New Password: ] |
|
|
-T <realm prompt> − [Realm: ] |
|
|
A realm is really management device in that it allows different
scopes of authority to be all contained in a single password file. The
alternative is to have different password files for each different scope of
authority. Experience shows that this alternative is difficult to maintain.
There are two types of realms: specific realms and the wild-card realm
‘*’. The rules are: 1. if the realm is not the wild card realm, then the realm must match
identically. Realms are case sensitive. 2. if the realm is the wild card realm, then the rules depend on context: |
|
|
− validating users [-V] − there must be an entry for the wild
card realm. − changing password [-C] − if there is an entry which
satisfies the supplied (userid, password) pair, then all passwords for the
user are changed for all realms. This is a convenience feature to make it
easier for users to change passwords. − adding and deleting users [-A and -D] − as in -V, the wild card realm is taken literally as the realm to which to add users. |
|
|
Password file (see above) |
|
|
crypt(3) |
|
|
validate_user − resolves most errors by writing a message to stderr and the security system log and then dieing. |
|
|
probably |