ChorusOS man pages section 4CC: Files

passwd(4CC)

NAME

passwd- format of the password file

DESCRIPTION

The passwd files are files consisting of newline separated records, one per user, containing ten colon (:) separated fields. These fields are as follows:

name: User's login name.
password: User's encrypted password.
uid: User's id.
gid: User's login group id.
class: User's login class.
change: Password change time.
expire: Account expiration time.
gecos: General information about the user.
home_dir: User's home directory.
shell: User's login shell.

Lines whose first non-whitespace character is a pound-sign (#) are comments, and are ignored. Blank lines which consist only of spaces, tabs or newlines are also ignored.

The name field is the login used to access the computer account, and the uid field is the number associated with it. They should both be unique across the system (and often across a group of systems) since they control file access.

While it is possible to have multiple entries with identical login names and/or identical uids, it is usually a mistake to do so. Routines that manipulate these files will often return only one of the multiple entries, and that one by random selection.

The login name must never begin with a hyphen (-); also, it is strongly suggested that neither upper-case characters nor dots (.) be part of the name, as this tends to confuse mailers.

The password field is the encrypted form of the password. If the password field is empty, no password will be required to gain access to the machine. This is almost invariably a mistake. Since these files contain the encrypted user passwords, they should not be readable by anyone without appropriate privileges. Administrative accounts have a password field containing an asterisk (*) which disallows normal logins.

The group field is the group that the user will be placed in upon login. Although this system supports multiple groups (see groups(1)) this field indicates the user's primary group. Secondary group memberships are selected in /etc/group.

The class field is a key for a user's login class. Login classes are defined in login.conf, which is a database of user attributes, accounting, resource and environment settings.

The change field is the number in seconds, GMT, from the epoch, until the password for the account must be changed. This field may be left empty or set to 0 to turn off the password aging feature.

The expire field is the number in seconds, GMT, from the epoch, until the account expires. This field may be left empty or set to 0 to turn off the account aging feature.

The gecos field normally contains comma (,) separated subfields as follows:

user's full name
user's office location
user's work phone number
user's home phone number

This information is used by the finger(1) program, and the first field used by the system mailer. If an ampersand (&) character appears within the fullname field, programs that use this field will substitute it with a capitalized version of the account's login name.

The user's home directory is the full path name where the user will be placed on login.

The shell field is the command interpreter the user prefers. If there is nothing in the shell field, the Bourne shell (/bin/sh) is assumed. For security reasons, if the shell is set to a script that disallows access to the system (the nologin(4) script, for example), care should be taken not to import any environment variables. With sh(1), this can be done by specifying the -p flag. Check the specific shell documentation to determine how this is done with other shells.

YP/NIS INTERACTION

Enabling access to NIS password data

The system administrator can configure the system to use NIS/YP for its password information by adding special records to the /etc/master.passwd file. These entries should be added with vipw(1B) so that the changes can be properly merged with the hashed password databases and the /etc/passwd file (/etc/passwd should never be edited manually). Alternatively, the administrator can modify /etc/master.passwd in some other way and then manually update the password databases with pwd_mkdb(1M).

The simplest way to activate NIS is to add an empty record with only a plus sign (+) in the name field, such as this:

+:::::::::

The `+' will tell the getpwent(3STDC) routines in the standard C library to begin using the NIS passwd maps for lookups.

Note -

The entry shown above is known as a wildcard entry, because it matches all users (the `+' without any other information matches everybody) and allows all NIS password data to be retrieved unaltered. However, by specifying a username or netgroup next to the `+' in the NIS entry, the administrator can affect what data are extracted from the NIS password maps and how it is interpreted. Here are a few example records that illustrate this feature (Note that you can have several NIS entries in a single master.passwd file.):

-mitnick:::::::::
+@staff:::::::::
+@permitted-users:::::::::
+dennis:::::::::
+ken:::::::::/bin/csh
+@rejected-users::32767:32767::::::/bin/false

Specific usernames are listed explicitly while netgroups are signified by a preceding `@'. In the above example, users in the ``staff'' and ``permitted-users'' netgroups will have their password information read from NIS and used unaltered. In other words, they will be allowed normal access to the machine. Users ``ken'' and ``dennis'', who have been named explicitly rather than through a netgroup, will also have their password data read from NIS, except that user ``ken'' will have his shell remapped to /bin/csh. This means that value for his shell specified in the NIS password map will be overridden by the value specified in the special NIS entry in the local master.passwd file. User ``ken'' may have been assigned the csh shell because his NIS password entry specified a different shell that may not be installed on the client machine for political or technical reasons. Meanwhile, users in the ``rejected-users'' netgroup are prevented from logging in because their UIDs, GIDs and shells have been overridden with invalid values.

User ``mitnick'' will be ignored entirely because his entry is specified with a `-' instead of a `+'. A minus entry can be used to block out certain NIS password entries completely; users whose password data has been excluded in this way are not recognized by the system at all. (Any overrides specified with minus entries are also ignored since there is no point in processing override information for a user that the system isn't going to recognize in the first place.) In general, a minus entry is used to specifically exclude a user who might otherwise be granted access because he happens to be a member of an authorized netgroup. For example, if ``mitnick'' is a member of the ``permitted-users'' netgroup and must, for whatever the reason, be permitted to remain in that netgroup (possibly to retain access to other machines within the domain), the administrator can still deny him access to a particular system with a minus entry. Also, it is sometimes easier to explicitly list those users who are not allowed access rather than generate a possibly complicated list of users who are allowed access and omit the rest.

Note -

The plus and minus entries are evaluated in order from first to last with the first match taking precedence. This means the system will only use the first entry that matches a particular user. If, using the same example, there is a user ``foo'' who is a member of both the ``staff'' netgroup and the ``rejected-users'' netgroup, he will be admitted to the system because the above example lists the entry for ``staff'' before the entry for ``rejected-users''. If the order were reversed, user ``foo'' would be flagged as a ``rejected-user'' instead and denied access.

Lastly, any NIS password database records that do not match against at least one of the users or netgroups specified by the NIS access entries in the /etc/master.passwd file will be ignored (along with any users specified using minus entries). In our example shown above, we do not have a wildcard entry at the end of the list; therefore, the system will not recognize anyone except ``ken'', ``dennis'', the ``staff'' netgroup, and the ``permitted-users'' netgroup as authorized users. The ``rejected-users'' netgroup will be recognized but all members will have their shells remapped and therefore be denied access. All other NIS password records will be ignored. The administrator may add a wildcard entry to the end of the list such as:

+:::::::::/sbin/nologin

This entry acts as a catch-all for all users that don't match against any of the other entries. This technique is sometimes useful when it is desirable to have the system be able to recognize all users in a particular NIS domain without necessarily granting them login access. See the description of the shell field regarding security concerns when using a shell script as the login shell.

The primary use of this override feature is to permit the administrator to enforce access restrictions on NIS client systems. Users can be granted access to one group of machines and denied access to other machines simply by adding or removing them from a particular netgroup. Since the netgroup database can also be accessed via NIS, this allows access restrictions to be administered from a single location, namely the NIS master server; once a host's access list has been set in /etc/master.passwd, it need not be modified again unless new netgroups are created.

FILES

/etc/master.passwd: ASCII password file, with passwords intact
/etc/passwd: ASCII password file, with passwords removed
/etc/pwd.db: db-format password database, with passwords removed
/etc/spwd.db: db-format password database, with passwords intact

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Interface Stability	Evolving

BUGS

User information should (and eventually will) be stored elsewhere.

The YP/NIS password database makes encrypted passwords visible to ordinary users, thus making password cracking easier unless you use shadow passwords with the master.passwd maps and ypserv(1M) server.

Unless you're using ypserv(1M), which supports the use of master.passwd type maps, the YP/NIS password database will be in old-style (Sixth Edition) format, which means that site-wide values for user login class, password expiration date, and other fields present in the current format will not be available when a system is used as a client with a standard NIS server.

ChorusOS 5.0 Last Revised December 2001