Although users may be the reason for the existence of your UNIX system, they also can be the sysadmin's worst nightmare. Users are always making demands and changing things. The one thing that remains constant is that users come and go, but the system
As system administrator, you will have to add and remove users from the system. It is also your task to provide the default environment so users can get their jobs done. This chapter shows what makes up a user's account, how to create new user accounts,
and what to do when a user leaves and his account must be removed.
Users see UNIX as a home directory and a shell. Behind the scenes are many other files and parameters that affect the user. This section explains each part of the user's account and how it affects the user.
Every process in UNIX has a current directory. This is no different for the login shell for a user. The initial current directory for a login shell is called its home directory. The login program sets the HOME environment variable to the full pathname
to this directory. It is in this directory that the login shell looks for its start-up files. It is also in this directory that system daemons look for the following:
.Xauthoritythe processes that are allowed to access the X screen being used by this user.
.XdefaultsX programs keep default values for their options in this file.
.cshrccsh/tcsh start-up script.
.exrcvi/ex start-up script.
.forwardmail redirection file. In this file you place the address or addresses to forward your mail. It allows you to receive mail from many accounts on a single account, or to pass your mail through a program to filter it before reading it.
.historyholds the last set of commands you executed in the shell for use in the history shell command.
.ksh_envksh start-up script.
.logincsh login script, which is executed once at login after .cshrc.
.profilesh/ksh login script, which is executed once at login, after /etc/profile.
.rhoststhe remote hosts and users that are equivalent to this user. Equivalent means can log in as this user from a remote system without specifying a password and can access files and perform commands as this user on this system without being
challenged for a password. (Used by the networking commands rsh, rexec, rcp, and rlogin.)
.xinitrcX start-up file.
.xmodmaprcX keyboard remapping file.
Many other programs also look for special start-up files in the user's home directory.
In addition to the mail file, the user name might be listed in the systemwide mail alias file. This file resides in one of several places:
Regardless of where the alias file resides, it consists of lines containing the alias and the mail address to use for mail received for that alias. Aliases are checked before local user names when mail is being delivered, so you can even alias a local
user name to a different machine or user. Listing 36.1 is a small excerpt from a mail alias file. It has the required postmaster alias and some local aliases.
Listing 36.1. Excerpt from a sample mail alias file.
# Aliases can have any mix of upper and lower case on the
# left-hand side, but the right-hand side should be proper
# case (usually lower)
# >>>>>>>>>> The program "newaliases" will need to be run
# >> NOTE >> after this file is updated for any changes to
# >>>>>>>>>> show through to sendmail.
# Following alias is required by the mail protocol, RFC 822
# Set it to the address of a HUMAN who deals with this system's
# Sample aliases:
# Alias for distribution list, members specified here:
# Alias for distribution list, members specified elsewhere:
# Alias for a person, so they can receive mail by several names:
# Local aliases below #
TIP: As demonstrated in the end of Listing 36.1, it is wise to create full-name aliases. These aliases let someone be addressed by their full name, without the sender knowing the user name. Since aliases are
case insensitive, it doesn't matter how you list the full name. Remember, however, that delivery addresses (the part after the colon) are case sensitive.
An alias can point to another alias. Aliases listed in this file are systemwide, and are addresses to which another user can reply. This is not true of private aliases users might enter into their mail reader's start-up files.
Each user interacts with UNIX via a command shell. The command shells use a file in the user's home directory to customize themselves for each user. As administrator, it is your responsibility to provide a default shell customization file. There are two
different sets of customization filesthe one you use depends on the shell family being used. For shells that are derived from /bin/sh the initialization file is .profile, with the Korn shell using an additional file whose name is user definable, but
is often called .ksh_env. Shells derived from Berkeley's C-shell use .login and .cshrc. A short explanation of the purpose and contents of these 4 files is as follows:
This is the start-up file executed by Bourne (/bin/sh) and Korn (/bin/ksh) shells at login. This is the file where you place changes to environment variables and global settings. This file is executed after /etc/profile is executed.
The Bourne shell does not have a start-up file for nonlogin-level shells. The Korn shell does, as it supports aliases and functions that are not exported from the login shell to subshells. If the login shell, via the .profile file, exports the
variable ENV, each Korn shell will read the file named in that environment variable on start-up. This file should not include changes to environment variables, but should include function and alias definitions. For login shells, this file is run after
/etc/profile and .profile. For subshells, it is the only file executed.
This file is run only at login by the C-shell. It should contain environment variable and global settings. It is executed after /etc/cshrc and .cshrc are executed.
This file is run by all C-shells at start-up. It is used to initialize aliases and local variables. Changes to environment variables should not be made in this file. For login shells, this file is run after /etc/cshrc and before .login. For subshells,
it is the only file executed.
The system keeps track of users via an entry in the password database. This databases is maintained in the following ways:
SVR4 stylein /etc/passwd and /etc/shadow
NIS/NIS+in a networkwide database, and on the NIS/NIS+ master in files specified at the time that NIS/NIS+ is configured.
It really doesn't matter which method is used because all of them track the same information. It is this information that defines the user to the UNIX system.
CAUTION: In a networked environment, it is very important that every system on the network use the same user ID for the same user. Although NIS and other methods share the password information to achieve
this, that is not required. All that is required is that any systems that share files via NFS also share user IDs.
The passwd file, as shown in Listing 36.2, is composed of single-line entries. Each must appear on a single line and cannot be continued. All the lines must have seven fields, delimited by colons. No comments or blank lines are allowed in this file.
This file is world readable, so it does not contain plain-text passwords.
Listing 36.2. Excerpts from a sample /etc/passwd file from an SVR4 system.
smtp:x:0:0:mail daemon user:/:
Pwcsite:x:9001:9:PPP from wc:/:/usr/sbin/aspppls
nobody:x:60001:60001:uid no body:/:
noaccess:x:60002:60002:uid no access:/:
CAUTION: Be very careful that all the lines have six colons separating the seven fields. A blank line will be taken as an alternate entry for the root user with no password.
The seven fields, in order, in the passwd file are described in the following sections.
This is a one- to eight-character alphanumeric field that represents the user's login name. Traditionally the name is all lowercase characters. Any value may be used for this field. To make it easy to tell a user name from a user ID, the name should not
start with a number.
TIP: Accounts fall into two basic categories: human users and computer users. UUCP accounts are an example of the latter. To make it easy to spot accounts that are used by other computers to log in for uucp
transfers, a convention is to start all those user names with an uppercase U.
The users password, encrypted with a one-way cipher is stored in the second field. Only the first 8 characters of the password are used. These are mixed with a 2-character salt to produce a 13-character encrypted password. When it is necessary to
compare a password, the plain text is encrypted with the salt, and a comparison is made against the encrypted version. If the passwd field is empty, this account has no password, and none is required to log in.
On systems that support password aging and place the password in the passwd file, the password data can be followed by a comma and four characters that describe the aging information. Each of these characters is drawn from the following character set:
. = 0
/ = 1
09 = 211
AZ = 1237
az = 3863
The first character after the comma denotes the maximum number of weeks the password is valid. The second character is the minimum number of weeks required between password changes. If both of these characters are zero (..), the user is forced to change
his password the next time he logs in. If the change interval is larger than the valid interval, only the root user can change the password.
The remaining two characters are the number of weeks since the epoch when the password was last changed. In UNIX, the current epoch, or beginning of time, is January 1, 1970, 00:00 GMT.
NOTE: You must manually edit the passwd file to set the aging characters the first time. They are not created automatically by the system. Be sure to use vipw when editing the passwd file to be sure it is
locked while you are in it.
On systems that do not use the passwd file to hold the password, such as those using /etc/shadow or some password adjunct scheme, this field contains a fixed string that has fewer than 13 characters.
TIP: If you need to temporarily lock out a user, insert the string *LK* on the front of that user's encrypted password string. It now will never match any valid password, as the encryption string uses the
same character set as the aging characters, and * is not in the set. You can delete *LK* from the front when you need to re-enable the account, and the original password is intact.
NOTE: To lock an account against being used for logins, use a fixed string that contains an invalid password character to prevent logins. The convention is to use *LK* for accounts that are locked against
UNIX internally uses a numeric ID to refer to a user. This is the user ID field of the passwd file. It is a number in the range 032767 on older systems, 065535 on some systems, and 02147483648 on SVR4 systems. The number 0 is reserved
for the root user, the user with special privileges. Many networked systems save -1 for no access and -2 for nobody.
CAUTION: These two values, -1 and -2, have been known to be a security hole. On systems that did not handle sign extension correctly in the user ID, any user ID that mapped to a negative value caused a
security hole due to other assumptions those systems made about checking. They have been replaced by positive values for noaccess and nobody.
noaccess is the value to use when a file is to be made so that it is not owned by root, but no one will be able to access it. nobody is used by NFS. Remote users with the ID 0 (root) are mapped to the nobody ID on NFS accesses unless the file system is
exported with root access permission. See Chapter 37, "Networking," for more details.
TIP: Although you have total control over the user IDs, it is best to follow a convention that will make it easier to determine which IDs are being used for which purpose.
UNIX has several accounts that are required. These all have low numbered IDs. It's wise to reserve all the IDs below 100 for these reserved system accounts.
In addition, there are several accounts that are for nonhuman use. These include UUCP access accounts and file ownership accounts. (A file ownership account is one that has no person associated with it, but is designed to hold the ownership of a set of
files for a department. Then when changes to those files need to be made, any member of the department can su to that user to make the changes.
Consider breaking the numbering space apart into the following:
Restricted accountssystem use: 099
Networkwide user accounts10019999
System restricted user accounts2000029999 (These are still unique on the network, but the account is valid only on one system.)
UUCP access accounts3000030999
File ownership accounts3100031999
Of course, if you need more accounts than this scheme supports, and if your system supports extended user IDs, move the regions around to make them bigger.
UNIX file permissions have three fields: owner (user ID), group (group ID), and world. The default group for files created by this user is the ID listed for this field. Groups are listed in the file /etc/group or in the file specified by the NIS/NIS+
NOTE: As with user IDs, consider breaking up this numbering space as well. A numbering scheme similar to the one proposed for user IDs is just as valid.
In the original versions of UNIX at Bell Laboratories, UNIX was also used as a front end computer to submit jobs to the GE/Honeywell mainframe. This system ran GECOS/GCOS, and this field was used to store the mainframe account information for this user.
This is obsolete and of little use outside the labs, so this field was usurped and used to hold the full name of the user. It is used for placing the full name on printouts and on electronic mail. It is stored in one of two formats:
System V Format: nnnn-Name(nnnn)
The first four digits are the GCOS account number. The name is everything after the - and before the (. The number in the parentheses is the GCOS box number.
Berkeley Format: Name, comments
Everything in the field up to the comma is the name. After the comma can go comments about the account that are not part of the name.
The login program changes to this directory before starting the shell, and sets the HOME environment variable to its value. The user's login scripts can change this value and define a different home directory, which is why this is called the initial
This field contains the full pathname of which script or program is started by the login program as the shell. If this field is empty, the Bourne shell is used by default. For UUCP accounts, the full pathname to the uucico program is the program to be
run by login, and it appears in this field.
Since the passwd file is world readable, as an added measure of security, SVR4 UNIX systems use a shadow file to hold the password information. It is readable only by root. It contains the password field data in an expanded format.
The shadow file, as shown in Listing 36.3, is not designed to be edited directly, but instead is modified by the passwd command automatically as needed. The passwd command has the ability to convert dates from standard format to the number of days since
January 1, 1970, as needed in the date fields in this file.
Listing 36.3. Excerpts from a sample /etc/shadow file from an SVR4 system.
The user's password, encrypted with a one-way cipher, is stored in the second field. Only the first 8 characters of the password are used. These are mixed with a 2-character salt to produce a 13-character encrypted password. When it is necessary to
compare a password, the plain text is encrypted with the salt, and a comparison is made against the encrypted version. If the passwd field is empty, the account has no password, and none is required to log in.
The user is not allowed to change his password until the number of days specified in this field after the last password change. The number of days is specified by the system administrator. 0 means that no limit is enforced, and the user may change his
password at anytime.
Group nametext name of the group, up to eight alphanumeric characters. Again, to avoid confusion with IDs it's best to begin with a letter.
Group passworda password that users can use with the newgrp command to make this group their current default group ID.
Group IDthe numeric representation of the group name.
Membersnames of users who are members of this group. It is this section that is scanned to determine the other groups to which a user belongs.
CAUTION: Many systems have a limit as to the number of groups to which a user can belong. The most common limit is 16. Placing a user in more than this number of groups prevents the user from being able
to log in at all.
Rather than building all of the configuration files by hand for each user as you create the user, UNIX provides the concept of a skeleton user. The files created for the skeleton are copied automatically to the home directory of the newly created user.
The skeleton is located in /etc/skel. Any files found in this directory are copied by the useradd command to the newly created home directory. Note that the useradd command allows using alternate skeletons via the -k argument.
Edit the passwd, shadow, and associated files yourself by hand.
Use the useradd command.
Use the specialized Graphical User Interface (GUI) interface provided by your UNIX vendor, such as admintool under Solaris or LoginMgr under UnixWare.
It is no longer recommended using the first option to prevent errors. The useradd command is very easy to use, and can handle all the internal security files directly. The GUI interfaces are also very easy to use and will guide you through the steps.
In any case, before actually adding the user you need to do the following:
Choose a user nameOften used are the first name, the first name with the first letter of the last name, the last name, the first letter of the first name and the last name. It really doesn't matter. Each name must be unique in the network and
consistent on all machines the user is valid to log into.
Assign a user IDUse the grouping of user ID values previously described and choose a user ID that has never been used. It is not a good idea to recycle user IDs, as a file in the system might still be owned by the old user of that ID, and would
then belong to the new user of that ID.
Choose group membershipsDetermine which groups best fit this user as the primary group and as supplemental groups.
Choose the location for the user's home directoryUsing symbolic links you can later move the home directory to any disk drive that has storage. Consider using a common /home directory and symlinks to where space is available, on an as-needed
The following list goes over where each of these arguments ends up in the files:
-c commentThis is the GCOS field of the /etc/passwd file. Put the full information for this field here. Use the Berkeley format if you do not need the GCOS features. Here is an example of a - c argument:
-c "Syd Weinstein, Room 101"
-d dirThis is the home directory field of the /etc/passwd file:
-e expireThis is the ending date for this login. This field is not required, and if omitted no expiration date will be used. The date is converted from the input format to the days since January 1, 1970, and placed in the /etc/shadow file. Any
input date format except a Julian date can be used. For example:
-e "January 1, 1995" or -e 1/1/95
-f inactiveThis is the maximum number of days this login can be inactive before being invalidated. It is stored in the number of days inactive field of the /etc/shadow file. If this argument is omitted, no checking for inactivity is performed.
-g groupThis is the primary group ID field of the /etc/passwd file. Either a group name or a numeric ID may be supplied.
-G group [, group .\x11.\x11. ]These are the secondary groups. The user's name is added to each of these group entries in the /etc/group file. Again, either a name or a numeric ID may be supplied.
-m [ -k skel_dir ]If no -k argument is given, create a home directory for this user and copy the files from:
If the -k argument is given, create a home directory and copy the files from the specified directory instead of the default /etc/skel directory.
-u uid [ -o]This is the user ID field of the /etc/passwd file. If the -o flag is given, the uid does not have to be unique. It is not recommended for more than one user to share a user ID.
-s shellThis is the full pathname of the login shell and is the shell field of the /etc/passwd file.
loginThis is the login name you have assigned this user.
After the user is added you should update the mail alias file. Add an alias for this user for the full spelling of his name to map to his user name. After the aliases are added, run the newaliases command to compile the alias hash table.
If you are running NIS, most of this doesn't apply to you, although understanding it will help you do what NIS needs. NIS uses a different set of configuration files that parallel the /etc/passwd file. The files used are totally under your control, but
a common convention is to use /etc/passwd for accounts local to this machine and /etc/yppasswd for the remainder of the accounts. See Chapter 37 for more information on NIS.
The first thing to understand about removing a user is don't. When a user must be denied access to the UNIX system, disable him instead. You don't want to remove him for the following reasons:
By not deleting, you prevent reuse of user IDs
You need to track which user IDs have been used to avoid reuse. One way of knowing this is to keep an entry in the password file with the deleted user's ID.
You may need to recover old files
When you recover files from an old tape, some of them might belong to the deleted user's ID. If the entry still exists, ls will be able to tell you who they belonged to so you can reassign them. This is another reason not to reuse user IDs.
It is very easy to disable the user's login. An option to the passwd command, when run by root, will mark the login as locked. Once locked, the user will not be able to log in. The command to lock a user is:
passwd -l user
CAUTION: Just locking the account is not enough. You need to do the following:
Make sure the user is not logged on anywhere in the network. If so, he could use the passwd command to re-enable his login.
Remove or move to another name the .rhosts file in his home directory to prevent him from logging in as himself from another system.
Check the system to make sure there are no setuid programs with his user ID. This can be done with the command
find / -user user_name -perm -04000 -print
Any of these files should be modified to clear the setuid bit. If a production application requires these files to have this bit set, have someone verify that these files are not a security risk.
Remember to run the find command on every system in the network.
After the user's login has been disabled, you need to clean up after him. This takes four steps:
Find files owned by this user.
The find command traverses the file systems and prints the names of all files owned by this user. The ones in the user's home directory tree may be obvious, but there often are others elsewhere in the hierarchy. For example
find / -user user_name -print
prints a listing of the names of all the files owned by the user user_name. This should be run on each system in the network.
Back up the files to tape.
In case you make a mistake, or there is a question later, make a tape backup of all of this user's files.
Reassign the ownership of files you desire to retain.
This is performed with the chown command.
Remove the remaining files you wish to discard.
You can use the xargs command with the files left on the list after you have deleted all the ones you reassigned ownership with the command
When you are sure you no longer need to access this user ID, because all the files have been handled and the home directory is removed, it's time to make the remaining password entry totally unusable by any shell program.
CAUTION: After you do this you will be unable to su to this user ID, so be sure you really do not need to be this user anymore before clearing the entry.
To make sure that the password entry is only used as a uid placeholder, four fields in the entry should be changed:
User nameWhile the user name is available, it can still receive mail. This can cause any mail being received for this now-deleted user to clutter up your mail spool directory. Changing the user name will cause any mail received for this user to
bounce back to the sender.
So that you know the entry is now a placeholder, use a pattern for the login name, perhaps d_uid, to indicate that this is a deleted entry for uid uid.
GCOS (comment/full name)Update the full name field to show when this entry was deleted. Leave the old user's name in there so you know who it belonged to when files are recovered that have this owner ID.
Home directoryTo prevent logging in to this user, set the login directory to a known nonexistent directory. This will prevent others from using su to use this user ID.
Login shellFinally, change the shell to /usr/bin/false. This will also prevent any accesses by remote commands for this user. This is accomplished with the usermod command:
usermod -l d_100 -c "Syd Weinstein, deleted 4/1/94 by ssw"\
-d /nodir -s /usr/bin/false syd
The last step is to remove this user from any mail aliases to which he was a member. This is done by editing the alias file and searching for all occurrences of the user name. Remember also to remove occurrences of alternatives to his name listed in the
When the backups have rolled around, such that there are no longer any tapes from when this user was around, and you are sure you will never need the ID again, you can remove the placeholder from the /etc/passwd file to reduce the clutter in that file.
Dealing with user accounts is much easier once you know where everything is located. This chapter shows you where the UNIX system keeps the information on the user's account. With this information you can decide which options to the useradd, usermod,
groupadd, and groupmod commands you need to use. You can even decide if you need to directly edit the files and go around these commands (but be cautious if you do so!).
The new user's account starts with the skeleton. It's from the skeleton that the initial contents of his home directory are created. You have to create the skeleton to meet your local needs. A simple default is delivered with the UNIX system, but it is
up to you to modify that to fit local conventions.
Finally, eventually you need to remove users. This chapter gives a set of steps you can follow when that becomes necessary.