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:
Many other programs also look for special start-up files in the user's home directory.
Each user on a UNIX system is eligible to receive electronic mail. Normally, this file is in one of these systemwide spool directories:
Some systems now place this mail file in the user's home directory. No matter where it's located, this file will hold the mail this user has yet to read, delete, or move into other folders.
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.
## # 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 Postmaster: root nobody: /dev/null # Sample aliases: # Alias for distribution list, members specified here: #staff:wnj,mosher,sam,ecc,mckusick,sklower,olson,rwh@ernie # Alias for distribution list, members specified elsewhere: #keyboards: :include:/usr/jfarrell/keyboards.list # Alias for a person, so they can receive mail by several names: #epa:eric ####################### # Local aliases below # ####################### Syd.Weinstein: syd Sydney.Weinstein: syd
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:
The system keeps track of users via an entry in the password database. This databases is maintained in the following ways:
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.
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.
root:x:0:1:0000-Admin(0000):/:/sbin/sh daemon:x:1:1:0000-Admin(0000):/: bin:x:2:2:0000-Admin(0000):/usr/bin: sys:x:3:3:0000-Admin(0000):/: adm:x:4:4:0000-Admin(0000):/var/adm: lp:x:71:8:0000-lp(0000):/usr/spool/lp: smtp:x:0:0:mail daemon user:/: uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp: nuucp:x:9:9:0000-uucp(0000):/var/spool/uucppublic:/usr/lib/uucp/uucico listen:x:37:4:Network Admin:/usr/net/nls: syd:x:201:200:Syd Weinstein:/home/syd:/usr/bin/ksh Pwcsite:x:9001:9:PPP from wc:/:/usr/sbin/aspppls nobody:x:60001:60001:uid no body:/: noaccess:x:60002:60002:uid no access:/:
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.
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:
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.
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.
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.
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+
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:
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.
root:03de466J423f5:6445:::::: daemon:NP:6445:::::: bin:NP:6445:::::: sys:NP:6445:::::: adm:NP:6445:::::: lp:NP:6445:::::: smtp:NP:6445:::::: uucp:NP:6445:::::: nuucp:NP:6445:::::: listen:*LK*::::::: Pwcsite:x3d5dtyfetonK:8774:::::: syd:43ASxete436h.:8776:0:168:7::: nobody:NP:6445:::::: noaccess:NP:6445::::::
The shadow file consists of the following fields:
This name is used to match against the name in the passwd file.
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 number of days between January 1, 1970, and the date that the password was last modified. It is stored as an integer value. All the remaining day fields are relative to this date.
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.
The user is required to change his password when the number of days specified in this field has passed since the last change. An empty field means the password never expires.
Beginning this many days before password expiration, on login the user is warned that his password is about to expire and will need to be changed.
If the account is inactive for more than this number of days, the login is considered locked and requires administrative action to reset a new date.
After this date, again specified as the number of days since January 1, 1970, the account is locked and may not be used for login.
A user can belong to more than one group. He has access rights to files in every group of which he is a member. The groups file, like the passwd file, is delimited by colons as shown in Listing 36.4.
root::0:root other::1: bin::2:root,bin,daemon sys::3:root,bin,sys,adm adm::4:root,adm,daemon uucp::5:root,uucp mail::6:root tty::7:root,tty,adm lp::8:root,lp,adm nuucp::9:root,nuucp staff::10: daemon::12:root,daemon nobody::60001: noaccess::60002:
The following are the fields in the group file:
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.
In the /etc/skel directory there are the following files:
Edit these files to alter the path lines for local conventions, and to add any local start-up options desired.
Samples named .login, .cshrc, and .profile can be found on the CD-ROM, along with a file named .ksh_env.
In addition to the default shell files, a user skeleton should consider adding the following:
You add these files not just to change the defaults but to show the users what files they can customize and what the current values are.
There are three ways to add a user:
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:
The useradd command takes many arguments that specify the answers to the questions you asked yourself in the previous section. From the man page, the command line arguments are these:
useradd [ -c comment ] [ -d dir ] [ -e expire ] [ -f inactive ] [ -g group ] [ -G group [, group...]] [ -m [ -k skel_dir ]] [ - u uid [ -o]] [ -s shell ] login
The following list goes over where each of these arguments ends up in the files:
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:
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
After the user's login has been disabled, you need to clean up after him. This takes four steps:
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.
To make sure that the password entry is only used as a uid placeholder, four fields in the entry should be changed:
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.