![[EdCert previous]](../../edcert/images/prev.gif)
![[EdCert next]](../../edcert/images/next.gif)
![[EdCert top]](../../edcert/images/top.gif)
One thing that Unix is frequently accused of not doing well is security. In terms of system administration, this means that the way user accounts are added to a system is of particular importance. If this is done wrong the security of the system can be severely compromised.
Each user on a system must have a login account identified by a unique username and UID number. Unique means that within a domain, like indiana.edu, there can only be one user with the same username. Login names are typically all lowercase and a maximum of eight characters.
Most organizations with many users will establish a set way to form usernames. IU usernames are now last name based. This hasn't always been the case, so there are IU users whose username may be their first name or something else.
Each user must also have a unique UID (user ID) number. This is an integer between 0 and 32767, although some systems permit numbers up to 65534. In networks using NFS the UID must be unique across the network, as well as being attached to the same username and person. UID numbers are conventionally assigned to human users beginning with 100. Numbers less than 100 are reserved for system accounts.
1. Is it important that the username as well as UID always refer to the same person?
Some UID numbers are assigned to system accounts during the installation of the operating system. What numbers are assigned to what accounts will vary between types of Unix. Some typical system accounts and UID's are listed below.
For IRIX:
For Solaris:
For HP-UX:
It is recommended that UID numbers not be reused, even if the user has left the system. If system files are ever restored from tape reusing UID numbers can cause problems as users are identified by UID number on tape.
Each user in a system belongs to at least one group. Users may belong to multiple groups, up to a limit of eight or 16. A list of all valid groups for a system are kept in /etc/group. This file contains entries like:
work:*:15:trsmith,pmayfiel,arushkin
Each entry consists of four fields separated by a colon. The first field holds the name of the group. The second field contains the encrypted group password and is frequently not used. The third field contains the GID (group ID) number. The fourth field holds a list of the usernames of group members separated by commas.
2. If a group does not require a password then the password field can be left blank.
GID's, like UID's, must be distinct integers between 0 and 32767. GID's of less then 10 are reserved for system groups. These default GID's are assigned during the installation of the operating system. Typical system groups and GID's are listed below.
For IRIX
For Solaris:
For HP-UX:
The /etc/passswd file contains a list of users that the system recognizes. Each user's login name must be in this file. Entries in /etc/passwd look something like this:
arushkin:Igljf78DS:132:20:Amy Rushkin:/usr/people/arushkin:/bin/csh
trsmith:*:543:20:Trent Smith, sys adm:/usr/people/trsmith/:/bin/tcsh
Although these entries differ in terms of the way the information is presented within the fields, they are both valid /etc/passwd entries. The first field contains the user's login name. The second contains the user's password. In the entry for arushkin the password has been encrypted by the system and appears as a nonsensical string of characters. In the entry for trsmith the password field is occupied by a placeholder. This can mean that the user does not have a password. In the /etc/group file, if a group does not use a password a placeholder is put in the password field rather than leaving the field blank. A blank field constitutes a security hole through which an unauthorized user could gain access to the system. A placeholder in the password field can also indicate that a shadow password file is in use. In that case, the actual password is kept in /etc/shadow.
The third field holds the user's UID and the fourth contains the default GID. The GID is the number of the group that the user is a member of when they log in. The fifth field is the GCOS field. It has no defined syntax and is generally used for personal information about the user; full name, phone number, etc. Frequently this field is not used at all. The sixth field contains information about where the users home directory is located. The last field contains the login shell. This is the shell that login starts for the user when they log in.
The /etc/passwd file is world readable, but /etc/shadow is readable only by root. SVR4 based systems support pwconv, which creates and updates /etc/shadow with information from /etc/passwd. When /etc/shadow is used an 'X' is placed in the password field of each entry in /etc/passwd. This tells pwconv not to modify this field because the passwords are kept in /etc/shadow.
If /etc/shadow doesn't exist pwconv will create it using the information in the /etc/passwd file. Any password aging controls found in /etc/passwd will be copied to /etc/shadow. If the /etc/shadow file already exists, pwconv adds entries in /etc/passwd to it as well as removing entries that are not found in /etc/passwd.
Entries in /etc/shadow look something like this:
trsmith:56HnkldsOI2Z:543:14:180:10:60::
The first field contains the user's login name and the second holds the user's encrypted password. The third contains the date that the user's password was last changed. The fourth sets the minimum number of days that a password must be in existence before it can be changed. The fifth field sets password's life span. This is the maximum number of days that a password can remain unchanged. If this time elapses and the user does not change the password, the system administrator must change it for them. The sixth field is used to dictate how long before the password's expiration the user will begin receiving messages about changing the password. The seventh contains the number of days that an account can remain inactive before before it is disabled and the user can no longer log in. The eighth field can be used to specify an absolute date after which the account can no longer be used. This is useful for setting up temporary accounts. The last field is the flag field and is not used.
Not all flavors of Unix use all of these controls. In addition, the syntax of aging controls varies from platform to platform. To find out which aging controls can be set on a particular system it is best to consult the man page for passwd, usermod, etc. On some systems aging controls can also be added to an account at the time it is created using graphic tools.
The use of shadow passwords is fairly recent addition to Unix. Under older operating systems, such as SunOS, shadow passwords are not included as part of the standard distribution. Several attempts have been made to implement a shadow password program, Shadow Suite, for Linux. However, all but the current beta version contained bugs which caused serious security problems. For optional information on the status of Shadow Suite, see the Linux Shadow Password HOWTO.
Different "flavors" of Unix provide different tools or scripts to use when creating and deleting user accounts. HP-UX uses SAM, the System Administration Manager. IRIX has User Manager, found in the System pull down menu. Solaris provides the admintool and useradd utilities. Under Solaris 2.5, the graphic interface to the admintool looks very much like SAM. With these tools creating a user account is simply a matter of entering information when prompted. The tool takes that information and creates the account. There are also scripts to create accounts, such as adduser, that can be started from the command line. This script is available from a variety of sources, including the CD that comes with the second edition of the UNIX System Administration Handbook. Linux comes with an adduser program.
It is a good idea to understand how a new account is created so that it can be done manually if necessary. Creating a new account involves:
If at all possible is a good idea not to edit the /etc/passwd file manually. Modifying this file by hand will eventually cause it to become corrupted and a corrupt /etc/passwd file is security risk. If a situation arises in which the file must be modified by hand it is crucial that a copy of the file be made before it is modified. This way if the file does become corrupt, an uncorrupted copy still exists. When the file is modified manually, the sequence of opening the file, writing to it, and closing it should occur on three consecutive command lines. This way the file is not open any longer than absolutely necessary.
BSD derivative systems, like SunOS, use vipw to edit the password file. Some distributions of Linux also supply this command. vipw is a special version of the vi editor. It makes a copy of /etc/passwd named ptmp that is then edited. When this copy is made the password file is locked so that no one can execute it while it is being edited. This is done to avoid a race condition. If a user executes the file while it is being edited a race begins to see which process writes to the file first. After changes to ptmp are complete vipw checks the consistency of the root entry before writing ptmp back to /etc/passwd. vipw is available for other systems, like Solaris, as part of the SunOS/BSD Compatibility Package Commands.
The script will automatically select a UID and GID for the new account, defaulting to the next highest unused integer. The system administrator can change both of these values if a specific number is desired. The script may also set a default home directory name. By convention home directories are given the name of the user's login. The default login shell on most systems is the Bourne shell. If the user has another shell preference or the system administrator wants the user to use a different shell this can be changed.
The default settings used by the script that creates user accounts are referred to as skeleton files. They are kept in /usr/skel, /etc/skel or /etc/security.
A script can also be used to edit /etc/group. Solaris supports the groupadd command for adding users to existing groups or adding new groups to the system. BSD uses set group. BSD also differentiates between the real group and group set. A users real group is the group specified in /etc/passwd. The group set is entire set of groups to which the user belongs. If /etc/group is modified manually it is a good idea to take the same precautions as when editing /etc/passwd by hand.
4. Does the user have to be added to /etc/group?
After editing /etc/passwd or /etc/group manually, pwck and grpck can be run to check the entries in these files for inconsistencies.
A home directory for the new user can be created using the mkdir command. This directory must have the same name as the home directory specified in /etc/passwd. At the time it is created the directory will be owned by root. The system administrator must use the chown and chgrp command to change the directories ownership. The adduser script includes the option to have the home directory created automatically. Additional information is needed to create accounts with useradd on Solaris systems.
The startup files for a system are also known as the 'dot files' (because the file names begin with a period 0. The names of some of the startup files vary according to which shell is selected in /etc/passwd.
Shell Script started at Script run every time
login a new shell is started
Bourne shell .profile none
(sh)
C shell .login .cshrc
(csh)
TC shell .login .tcshrc
(tcsh)
Korn shell .profile .kshrc
(ksh)
Bourne Again Shell .profile .bashrc
(bash)
Other dot files include:
File Used for .exrc Setting vi editor options .emacs_pro Setting emacs options .newsrc Specifying newsgroups of interest .Xdefaults Specifying X Windows configuration .xinitrc Specifying initial X Windows environment
On some systems these files may be copied from general skeletal startup files in /usr/local/skel. SGI provides /etc/stdcshrc, /etc/stdlogin, and /etc/stdprofile as skeletal startup files for the C and Bourne shell.
In order for user to utilize the new account it must have a password. The initial password is set by the system administrator and can be changed by the user.
Most systems provide a script, such as userdel for deleting user accounts. It can also be done with the graphical tools provided by the system. If the need arises to do it manually the process of deleting a user consists of :
Once a user's initial account information is established it can be changed manually or with various scripts. Solaris provides the usermod for changing users status as well as groupadd, groupmod, and groupdel for modifying groups. BSD supports the groups command for changing the group set or the designated real group. If groups is used with login name as an option it will list all the groups to which that user belongs.
In addition many systems support commands such as passwd that allow users to change their own passwords. After a password has been changed the netpass command can be used to change the password across the network.
The status of a user account can also be changed with the tools provided by various Unix "flavors". Under IRIX the User Manager can be used. In HP-UX SAM can be used to change information about a current user as well as adding new users.
Terms used: UID GID, NFS.