UNIX System Administration Handbook - Evi Nemeth [59]
• The eighth field specifies the day (in days since Jan 1, 1970) on which the user’s account will expire. The user may not log in after this date until the field has been reset by an administrator. If the field is left blank, the account will never expire.
• The ninth field (the “flags” field) is currently always empty and is reserved for future use.
Now that we know what each of the fields means, let’s look at our example line again:
millert:inN0.VAsc1Wn.:11031::180:14::18627:
In this example, the user millert last changed his password on March 14, 2000. The password must be changed again within 180 days, and millert will receive warnings that the password needs to be changed for the last two weeks of this period. The account expires on December 31, 2001.
6.5 THE /ETC/GROUP FILE
The /etc/group file contains the names of UNIX groups and a list of each group’s members. For example:
wheel:*:0:root,evi,garth,scott,trent
csstaff:*:100:lloyd,evi
student:*:200:dotty
Each line represents one group and contains four fields:
• Group name
• Encrypted password (vestigial and rarely used)
• GID number
• List of members, separated by commas
As in /etc/passwd, fields are separated by colons. On some systems, group names must be 8 or fewer characters long. While it is possible to enter a group password (to allow users not belonging to a group to change to it by using the newgrp command), this is rarely done. Most sites put stars in the password field, but it is safe to leave the password field blank if you wish. The newgrp command will not change to a group without a password unless the user is already listed as being a member of that group.
Be careful not to inadvertently add spaces between the names of group members. Most systems will ignore everything after the first space.
As with usernames and UIDs, group names and GIDs should be kept consistent among machines that share files using NFS. Consistency can be tricky to maintain in a heterogeneous environment, since different operating systems use different GIDs for the same group names. We’ve found that the best way to deal with this issue is to avoid using a system group as the default login group for a user. This principle also applies to vendor-supplied groups such as “staff”.
To avoid collisions with vendor-supplied GIDs, we suggest starting local groups at GID 100, or after the vendor-supplied groups end, whichever is greater.
6.6 ADDING USERS
Before you create an account for a new user, it’s very important that the user sign and date a copy of your local user agreement and policy statement. (What?! You don’t have a user agreement and policy statement? See page 782 for more information about why you need one and what to put in it.)
Users have no particular reason to want to sign a policy agreement, so it’s to your advantage to secure their signatures while you still have some leverage. We find that it takes more effort to secure a signed agreement after an account has been released. If your process allows for it, it’s best to have the paperwork precede the creation of the account.
Mechanically, the process of adding a new user consists of three steps required by the system, two steps that establish a useful environment for the new user, and several extra steps for your own convenience as an administrator.
Required:
• Edit the passwd and shadow files to define the user’s account.
• Set an initial password.
• Create the user’s home directory.
For the user:
• Copy default startup files to the user’s home directory.
• Set the user’s mail home and establish mail aliases.
For you:
• Add the user to the /etc/group file.
• Configure disk quotas.