adduser, mkuser - Adds new accounts
adduser [ options ] [ interpreter ]
Adduser and mkuser work together to add new accounts to the system. Both require Super User (root) status to run. Without any arguments, adduser creates a staff level account, and uses csh as the command interpreter. The command interpreter, usually a shell of some sort, is the program that is run after the user logs in successfully. If an interpreter argument is given, it is used in place of csh.
The procedure for adding a new account involves choosing an account login name and password. Login names are 15 characters or less, begin with a letter, and can contain only letters or digits. Passwords can be up to 12 characters, are not case sensitive, and can contain any printable characters. If a password of “none” is chosen, the account is not asked for a password when logging in.
Options can be offered in the command line, instructing adduser to create different types of accounts. Options for specifying group type are:
root account. This level offers full privileges and total access to the system. Only one account on the system should have root status with access to an interpreter such as the C-Shell.
staff account. This level is for most users on the system. Staff users can be completely mobile around the system yet cannot view or access any sensitive material.
mail (network) account. This is for use by network computers in order to exchange e-mail, news, etc. This account does not have a user area.
guest account. This is the same as a staff account, except the guest must enter a name and location if no name is given to this account. Guest accounts cannot modify their Conference System information file.
These options specify other account attributes:
bypass accounting. This assigns a user-ID of 0 to the account. No user area is created, and no user information is requested. Adduser will only ask for a description of the account being created.
do not copy the default login and cshrc scripts to the user’s home directory. This is desired when assigning a command interpreter other than csh, as only csh executes these scripts.
do not prompt for user information, useful when creating a guest account. Usually, adduser asks for a user’s full name, address, and phone number.
no network access. This prevents a user from sending mail to offsite addresses in the network.
do not create a signature file for the user.
do not mail the welcome file to the user’s mailbox.
adduser -gun plush
Create a guest account, no user info, no network mail access, use plush (the ProLine User’s SHell) as the interpreter.
adduser -m mdss
Create a network mail login entry. Use mdss as the interpreter.
adduser -rau "adduser -s csh"
Create a login entry which runs adduser as the interpreter with options for setting up a staff account. This allows a caller to create an account without any administrator intervention. Although this example creates a root level account (adduser can only be run from a root process), the person using it causes adduser to create a personal staff level account.
If an account’s name or description is left blank, a login attempt using that account name will be prompted for a name and location. This is mainly used for guest accounts.
A typical user account is created in the following manner:
Adduser asks the user to fill in a number of information fields, then creates an entry in $/etc/passwd (see below for entry description). An account record is created for the user in $/etc/adm, a database containing statistics for each user of the system. An entry containing information about the newly created account is appended to the adduser.log file.
Adduser then transfers control to mkuser, a shell script that can further complete the installation of user accounts. Mkuser creates the user’s home directory. The default login and cshrc scripts are copied here for the user. A signature file may also be created.
A directory with the user’s login name is created in $/adm. This area is used by the system for storing the user’s data files.
A welcome file is sent to the user’s mailbox. This file contains a personal message from the administrator.
Since adduser can only create user accounts when it is invoked with
super user status, that allows mkuser to perform similar super user
functions. It is important to understand that mkuser is run under
the parent process that invoked adduser — IT IS NOT BEING RUN
AS IF IT WERE OWNED BY THE NEW USER BEING CREATED.
This means the user—AT NO TIME—should ever get interactive access to any part of the system that might lead to a security problem. Furthermore, invoking commands intended to effect the user being created is futile because the effective user is most likely to be root, the system administrator, or an account registration user with super user status, NOT the intended user.
Mkuser is provided to allow customized file control while an account is being created. In addition, the distribution version of mkuser lives in $/etc and should not be modified. A copy of mkuser can be placed into the effective user’s “~/bin” directory or into the system’s local “bin” directory (e.g., $/sys/local/bin) such that it takes precedence over the distribution version.
Adduser alphabetically inserts a new account entry into the password
file. Password entries have this format:
jdoe:ASji8aQd3pxYg:142:1:John Doe:usr/jdoe:csh
This corresponds to:
Login : Password : UID : GID : Name : Home : Interpreter
The user-id (UID) is a unique number identifying the user. The group-id (GID) is one of the following:
0 - Root-level account
1 - Staff-level account
2 - Network mail account
3 - Guest-level account
The user’s home directory and interpreter pathnames do not start with the system’s startup prefix ($/). This is added by login so that any name change of the startup prefix avoids a complete update of the password file. A path to the interpreter is not needed unless it does not reside in any of the standard directories for programs.
Adduser reads a resource file ($/etc/rsrc/adduser.rsrc) containing
information on account settings when adding a new user. The resource
file consists of five lines of information:
The total minutes per month the user can spend on the system each month. If the user overspends his allowance for the current month, access is denied until the beginning of the next month. Time allowances are reset at the beginning of each month. Default 1200 (40 minutes per day average). If set to zero, the time allowance is unlimited.
The number of days that may pass without logging in before the user is flagged for removal due to inactivity. If set to zero, the inactivity removal feature is disabled. Default 60 days.
The cost for access time in pennies per minute. A value of 1.5 would denote a 1.5 cent per minute access charge, or 90 cents per hour. Default 0 cents per minute (no access charge).
The number of accounts that can be active at any one time. Default 200 users.
If 0, adduser is specific in accepting input entered by the user. For example, it refuses to continue until the user enters exactly ten digits for the phone number. If 1, it is lenient about input, useful for systems that receive calls from users who live outside of the United States. Default 0 (no leniency)
If the resource file is not present, the default values are used.