• Choose a category
• All
• Classic-Fiction

• Host and TTY-based access control

• Default umask

• Account controls (minimum password length, password aging)

In this example, intended for a sysadmin, some of the default values are overridden:

sysadmin:\

:ignorenologin:\

:requirehome@:\

:maxproc=unlimited:\

:openfiles=unlimited:\

:tc=default:

Users in the sysadmin login class are allowed to log in even when /var/run/nologin exists, and they need not have a working home directory (this option allows logins when NFS is not working). Sysadmin users may start any number of processes and open any number of files.5 The last line pulls in the contents of the default entry.

6.4 THE SOLARIS AND RED HAT /ETC/SHADOW FILE

The use of a shadow password file is mandatory under Solaris. You can also use it under Red Hat Linux if you install the shadow package.

The /etc/shadow file is readable only by the superuser and serves to keep encrypted passwords safe from prying eyes. It also provides account information that’s not

available from /etc/passwd. Unlike the FreeBSD master.passwd file, the shadow file is not a superset of the passwd file, and the passwd file is not generated from it; you must maintain both files by hand.

Like /etc/passwd, /etc/shadow contains one line for each user. Each line contains nine fields, separated by colons:

• Login name

• Encrypted password

• Date of last password change

• Minimum number of days between password changes

• Maximum number of days between password changes

• Number of days in advance to warn users about password expiration

• Number of inactive days before account expiration (Solaris)

• Account expiration date

• Flags

The only fields that are required to be nonempty are the username and password. Absolute date fields in /etc/shadow are specified in terms of days (not seconds) since Jan 1, 1970, which is not a standard way of reckoning time on UNIX systems. Fortunately, you can use the usermod program to set the expiration field.

See page 92 for more information about usermod.

A typical shadow entry looks like this:

millert:inN0.VAsc1Wn.:11031::180:14::18627:

Here is a more complete description of each field:

• The login name is the same as in /etc/passwd. This field simply connects a user’s passwd and shadow entries.

• The encrypted password is identical in concept and execution to the one previously stored in /etc/passwd.

• The last change field indicates the time at which the user’s password was last changed. This field is generally filled in by /bin/passwd.

• The fourth field sets the number of days that must elapse between password changes. Once users change their password, they cannot change it again until the specified period has elapsed. This feature seems useless, and we think it could be somewhat dangerous when a security intrusion has occurred. We recommend against setting a value for this field.

• The fifth field sets the maximum number of days allowed between password changes. This feature allows the administrator to enforce password aging; see page 657 for more information. Under Linux, the actual maximum number of days is the sum of the maximum field and the inactive (seventh) field.

• The sixth field sets the number of days before password expiration that the login program should begin to warn the user of the impending expiration.

• Solaris and Linux differ in their interpretation of the seventh field. The Solaris behavior is as follows: If a user has not logged in to his or her account within the number of days specified in the seventh field, the account will be disabled. Disused accounts are a favorite target of hackers, and this feature attempts to give you a way to take such accounts “off the market.” However, it only works if the user can be found in the /var/adm/lastlog file; users that have never logged in will not be automatically disabled. This feature does not work very well in a networked environment because each host has its own lastlog file.

Under Linux, the seventh field has a completely different meaning: