passwd, group, shadow - user and group databases, shadow passwords
/etc/passwd lists all the users of the system, and /etc/group lists all
the groups the users may belong to. Both files also contain encrypted
passwords, numeric ID's etc. Encrypted passwords may be hidden in the
file /etc/shadow if extra protection is warranted.
Each file is an text file containing one line per user or group. The
data fields on a line are separated by colons. Each line in the password
file has the following form:
The name field is the login name of a user, it is up to 8 letters or
numbers long starting with a letter. The login name must be unique. The
password field is either empty (no password), a 13 character encrypted
password as returned by crypt(3), or a login name preceded by two number
signs (#) to index the shadow password file. Anything else (usually *)
is invalid. The uid and gid fields are two numbers indicating the users
user-id and group-id. These id's do not have to be unique, there may be
more than one name with the same id's. The gecos field can be set by the
user. It is expected to be a comma separated list of personal data where
the first item is the full name of the user. The dir field is the path
name of the users home directory. Lastly the shell field is the path
name of the users login shell, it may be empty to indicate /bin/sh. A
Minix specific extension allows the shell field to contain extra space
separated arguments for the shell.
Lines in the group file consist of four fields:
The name field is the name of the group, same restrictions as a login
name. The passwd field may be used to let users change groups. The gid
field is a number telling the group-id. The group-id is unique for a
group. The mem field is a comma separated list of login names that are
special members of the group. If a system supports supplementary group
id's then a user's set of supplementary group id's is set to all the
groups they are a member of. If a system allows one to change groups
then one can change to a group one is a member of without using the
The shadow password file has precisely the same form as the password
file, except that only the name or passwd fields are used as yet. The
other fields are zero or empty. A password in the password file may have
the form ##user to indicate the entry user in the shadow password file.
The password in this entry is then used for authentication of the user.
The shadow file can only be read by the privileged utility pwdauth(8), so
that the encrypted passwords in the shadow file are kept secret, and thus
safe from a dictionary attack.
Special password and group file entries
There are several entries in the password and group files that are
preallocated for current or future use. All id's less than 10 are
reserved. The special password file entries are:
uucp:*:5:5:UNIX to UNIX copy:/usr/spool/uucp:/usr/sbin/uucico
ast:*:8:3:Andrew S. Tanenbaum:/usr/ast:
The root id is of course the super user. The daemon id is used by some
daemons. Some devices are protected so that only those daemons can
access them. The bin id owns all sources and most binaries. The uucp,
news and ftp id's are for serial line data transfer, usenet news, or ftp
if so needed. The nobody id is used in those cases that a program may
not have any privileges at all. The ast id is the honorary home
directory for Andrew S. Tanenbaum, the creator of Minix. You can also
find the initial contents for a new home directory there.
The special group file entries are:
Groups with the same name as special user id are used with those id's.
The operator group is for the administrators of the system. Users in
this group are granted special privileges. The other group is for
ordinary users. The tty group is for terminal devices, and associated
set-gid commands. Same thing with the kmem group and memory devices.
/etc/passwd The user database.
/etc/group The group database.
/etc/shadow The shadow password file.
login(1), passwd(1), su(1), crypt(3), getpwent(3), getgrent(3),
The nobody and nogroup id's are likely to be renumbered to the highest
possible id's once it is figured out what they are.
Kees J. Bot (firstname.lastname@example.org)