Полезная информация

Previous Page TOC Next Page Home

36 — User Administration

By Sydney S. Weinstein

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 remains.

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.

What Makes Up a User Account

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.

The User's Home Directory

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.

The User's Mail File

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.

Mail Alias File Entries

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

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.

The Shell 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 files—the 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 User's passwd File Entry or NIS/NIS+ Database Entry

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.


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.

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:/:

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.

User Name

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.

Password (if Not Using a Shadow Password Scheme)

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.


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 login.

User ID

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 0—32767 on older systems, 0—65535 on some systems, and 0—2147483648 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:
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.

Default Group ID

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+ configuration.


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.

Full Name (GCOS Field)

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:

Initial Home Directory

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 home directory.

Shell

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.

Shadow File Entry (NIS/NIS+ database entry)

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:

User Name

This name is used to match against the name in the passwd file.

Password

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.

Password Last Changed Date

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.

Minimum Number of Days Between Password Changes

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.

Maximum Number of Days a Password Is Valid

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.


TIP: Do not enable password aging (leave this field blank) for UUCP accounts. The UUCP chat script cannot handle requests to change an expired password.

Number of Days to Warn User to Change passwd

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.

Number of Days the Login May Be Inactive

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.

Date When the Login Is No Longer Valid

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.

The /etc/group File

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:


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.

Building the Skeleton

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.

Creating Skeleton Shell Files

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.

Additional Files You May Wish to Create

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.

Adding a User

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.

Before Adding the User

In any case, before actually adding the user you need to do the following:

Running useradd

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:

Creating Mail Alias Entries

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.

NIS Effects

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.

Removing a User

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:

Disabling the User's Login

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.

Cleaning Up Disk Space Assigned to This User

After the user's login has been disabled, you need to clean up after him. This takes four steps:

  1. 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.

  2. 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.

  3. Reassign the ownership of files you desire to retain.

    This is performed with the chown command.

  4. 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

    xargs rm < remaining_list

Final User Removal After All Files Are Handled

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:

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 alias file.

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.

Summary

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.

Previous Page TOC Next Page Home