6.1 Unix Users and Groups

From the system's point of view, auser isn't necessarily an individual person. Technically, to the operating system, a user is an entity that can execute programs or own files. For example, some user accounts exist only to execute the processes required by a specific subsystem or service (and own the files associated with it); such users are sometimes referred to as pseudo users. In most cases, however, a user means a particular individual who can log in, edit files, run programs, and otherwise make use of the system.

Each user has a username that identifies him. When adding a new user account to the system, the administrator assigns the username a user identification number (UID). Internally, the UID is the system's way of identifying a user. The username is just mapped to the UID. The administrator also assigns each new user to one or more groups: a named collection of users who generally share a similar function (for example, being members of the same department or working on the same project). Each group has a group identification number (GID) that is analogous to the UID: it is the system's internal way of defining and identifying a group. Everyuser is a member of one or more groups. Taken together, a user's UID and group memberships determine what access rights he has to files and other system resources.

User account information is stored in several ASCII configuration files:

/etc/passwd: User accounts.
/etc/shadow: Encoded passwords and password settings. As we'll see, the name and location of this file varies.
/etc/group: Group definitions and memberships.
/etc/gshadow: Group passwords and administrators (Linux only).

We'll consider each of these files in turn.

6.1.1 The Password File, /etc/passwd

The file /etc/passwd is the system's master list of information about users, and every user account has an entry within it. Each entry in the password file is a single line having the following form:

username:x:UID:GID:user information:home-directory:login-shell

The fields are separated by colons, and blank spaces are legal only within the user information field.

The meanings of the fields are as follows:

username: The username assigned to the user. Since usernames are the basis for communications between users, they are not private or secure information. Most sites generate the usernames for all of their users in the same way: for example, by last name or first initial plus last name. Usernames are generally limited to 8 characters on Unix systems, although some Unix versions support longer ones.
x: Traditionally, the second field in each password file entry holds the user's encoded password. When ashadow password file is in use (discussed below) as is the case on most Unix systems this field is conventionally set to the single character "x". AIX uses an exclamation point (!), and FreeBSD and trusted HP-UX use an asterisk (*).
UID: The user identification number. Each distinct human user should have a unique UID. Conventionally, UIDs below 100 are used for system accounts (Linux now uses 500 as the cutoff, and FreeBSD uses 1000). Some sites choose to assign UID values according to some coding scheme where ranges of UIDs correspond to projects or departments (for example, 200-299 is used for chemistry department users, 300-399 is used for physics, and so on).

Multiple user accounts with the same UID are the same account from the system's point of view, even when the usernames differ. If you can, it's best to keep UIDs unique across your entire site and to use the same UID for a given user on every system to which he is given access.

GID

The user's primary group membership. This number is usually the identification number assigned to a group in the file /etc/group (discussed later in this chapter), although technically the GID need not be listed there.^[1] This field determines the group ownership of files the user creates. In addition, it gives the user access to files that are available to that group. Conventionally, GIDs below 100 are used for system groups.

^[1] Except under AIX. No one will be able to log in to an AIX system without a group file; similarly, any user whose password file entry lists a GID not present in /etc/group will not be able to log in.

user information

Conventionally contains the user's full name and, possibly, other job-related information. This field is also called the GECOS^[2] field, after the name of the operating system whose remote login information was originally stored in the field. Additional information, such as office locations and office and home phone numbers, may also be stored here. Up to five distinct items may be placed within it, separated by commas. The interpretations of these five subfields vary substantially from system to system.

^[2] Sometimes spelled "GCOS."

home directory

The user's home directory. When the user logs in, this is her initial working directory, and it is also the location where she will store her personal files.

login shell

The program used as the command interpreter for this user. Whenever the user logs in, this program is automatically started. This is usually one of /bin/sh (Bourne shell), /bin/csh (C shell), or /bin/ksh (Korn shell).^[3] There are also alternative shells in wide use, including bash, the Bourne-Again shell (a Bourne shell-compatible replacement with many C shell- and Korn shell-like enhancements), and tcsh, an enhanced C shell-compatible shell.

^[3] The actual shell programs are seldom, if ever, really stored in /bin in fact, many systems don't even have a real /bin directory but there are usually links from the real path to this location.

On most systems, the /etc/shells file lists the full pathnames of the programs that may be used as user shells (accounts with an invalid shell are refused login). On AIX systems, the valid shells are listed in the shells field in the usw stanza of /etc/security/login.cfg :

usw:  shells = /bin/sh,/bin/csh,/bin/ksh,/usr/bin/tcsh,...

Here is a typical entry in /etc/passwd:

chavez:x:190:100:Rachel Chavez:/home/chavez:/bin/tcsh

This entry defines a user whose username is chavez. Her UID is 190, her primary group is group 100, her full name is Rachel Chavez, her home directory is /home/chavez, and she runs the enhanced C shell as her command interpreter.

Since /etc/passwd is an ordinary ASCII text file, you can edit the file with any text editor. If you edit the password file manually, it's a good idea to save a copy of the unedited version so you can recover from errors:

# cd /etc  # cp passwd passwd.sav     Save a copy of the current file # chmod go= passwd.sav     Protect the copy (or use a umask that does this) # emacs passwd

If you want to be even more careful, you can copy the password file again, to something like passwd.new, and edit the new copy, renaming it /etc/passwd only when you've successfully exited the editor. This will save you from having to recopy it from passwd.sav on those rare occasions when you totally munge the file in the editor.

However, a better tactic is to use the vipw command to facilitate the process, allowing it to be careful for you. vipw invokes an editor on a copy of the password file (traditionally /etc/ptmp or /etc/opasswd, but the name varies). The presence of this copy serves as a locking mechanism to prevent simultaneous password-file editing by two different users. The text editor used is selected via the EDITOR environment variable (the default is vi).

When you save the file and exit the editor, vipw performs some simple consistency checking. If this is successful, it renames the temporary file to /etc/passwd. On Linux systems, it also stores a copy of the previous password file as /etc/passwd.OLD (Red Hat) or /etc/passwd- (SuSE).

The vipw command also has the advantage that it automatically performs or reminds you about other related activities that are required to activate the changes you just made. For example, on Solaris systems, it offers you the chance to edit the shadow password file as well. More importantly, on FreeBSD and Tru64 systems, it automatically runs the binary password database creation command, which turns the text file into the binary format used on those systems (pwd_mkdb and mkpasswd, respectively).

AIX does not provide vipw.

6.1.2 The Shadow Password File, /etc/shadow

Most Unix operating systems support a shadow password file : an additional user-account database file designed to store the encrypted passwords. On most systems, the password file must be world-readable in order for any command or service that translates usernames to/from UIDs to function properly. However, a world-readable password file means that it's very easy for the bad guys to get a copy of it. If the encrypted passwords are included there, a password cracking program could be run against them, and potentially discover some poorly chosen ones. A shadow password file has the advantage that it can be protected against anyone accessing it except the superuser, making it harder for anyone to acquire encoded passwords (you can't crack what you can't get).^[4]

^[4] Don't be too sanguine about this fact or let it make you complacent about user account security. Shadow password files provide another barrier against the bad guys, nothing more, and they are not invulnerable. For example, some network clients and services have had bugs in the past that made them vulnerable to buffer overrun attacks that could cause them to crash during their authentication phase. Encoded passwords from a shadow password file may be present in the resulting core dumps.

Here are the locations of the shadow password file on the various systems we are considering:

AIX	/etc/security/passwd
FreeBSD	/etc/master.passwd
Linux	/etc/shadow
Solaris	/etc/shadow

HP-UX and Tru64 store encoded passwords in the protected password database when enhanced security is installed (as we will see). Tru64 also has the option of using a traditional shadow password file with the enhanced security package.

At present, entries in the shadow password file typically have the following syntax:

username:encoded password:changed:minlife:maxlife:warn:inactive:expires:unused

username is the name of the user account, and encoded password is the encoded user password (often somewhat erroneously referred to as the "encrypted password"). The remaining fields within each entry are password aging settings. These items control the conditions under which a user is allowed to and is forced to change his password, as well as an optional account expiration date. We will discuss these items in detail later in this chapter.

The SuSE Linux version of the vipw command accepts a -s option with which to edit the shadow password file instead of the normal password file. On other systems, however, editing the shadow password file by hand is not recommended. The passwd command and related commands are provided to add and modify entries within the file (as we shall see), a task which can also be accomplished via the various graphical user account management tools (discussed later in this chapter).

6.1.2.1 The FreeBSD /etc/ master.passwd file

FreeBSD uses a different password file, /etc/master.passwd, which also functions as a shadow password file in that it stores the encoded passwords and is protected from all non-root access. FreeBSD also maintains /etc/passwd.

Here is a sample entry from master.passwd:

ng:encoded-pwd :194:100:staff :0 :1136005200 :J. Ng:/home/ng:/bin/tcsh

Entries in this file include three additional fields sandwiched between the GID and user's full name (highlighted in the example entry): a user class (see Section 6.2.9.2, later in this chapter), the password expiration date, and the account expiration date (the latter are expressed as seconds since midnight on January 1, 1970 GMT). In this case, user ng is assigned to the staff user class, has no password expiration date, and has an account expiration date of June 1, 2002. We'll consider these fields in more detail later in this chapter.

6.1.2.2 The protected password database under HP-UX and Tru64

Systems that must conform to the C2 security level (a U.S. government-defined system security specification) have additional user account requirements. C2 security requires many system features, including per-user password requirements, aging specifications, and nonaccessible encoded passwords. When the optional enhanced security features are installed and enabled on HP-UX and Tru64 systems, a protected password database is used in addition to /etc/passwd. (It is part of theTrusted Computing Base on these systems.)

Under HP-UX, the protected password database consists of a series of files, one per user, stored in the /tcb/files/auth/x directory hierarchy, where x is a lowercase letter. Each user's file is placed in a file named the same as his username, in the subdirectory corresponding to its initial letter: chavez's protected password database entry is /tcb/files/auth/c/chavez. On Tru64 systems, the data is stored in the binary database /tcb/files/auth.db.

The HP-UX files are structured as authcap entries (just as terminal capabilities are specified via termcap entries on some systems), consisting of a series of colon-separated keywords, each of which specifies one particular account attribute (see the authcap manual page for details).

All of this is best explained by an excerpt from chavez's file:

chavez:u_name=chavez:u_id#190:\        :u_pwd=*dkIkf,/Jd.:u_lock@:u_pickpw:chkent:

The entry begins with the username to which it applies. The u_name field again indicates the username and illustrates the format for attributes that take a character string value. The u_id field sets the UID and illustrates an attribute with a numerical value; u_pwd holds the encoded password. The u_lock and u_pickpw fields are Boolean attributes, for which true is the default when the name appears alone; a value of false is indicated by a trailing at-sign (@). In this case, the settings indicate that the account is not currently locked and that user chavez is allowed to select her password. The chkent keyword completes the entry.

Table 6-1 lists the fields in the protected password database. Note that all time periods are stored as seconds, and dates are stored as seconds since the beginning of Unix time (although the tools for modifying these entries will prompt for days or weeks and actual dates).

Table 6-1. Protected password database fields
Field	Meaning
u_name	Username.
u_id	UID.
u_pwd	Encrypted password.
u_succhg	Date of last successful password change.
u_lock	Whether the account is locked.
u_nullpw	Whether a null password is allowed.
u_minlen	Minimum password length in characters (Tru64 only).
u_maxlen	Maximum password length.
u_minchg	Minimum time between password changes.
u_exp	Time period between forced password changes.
u_life	Amount of time after which account will be locked if password remains unchanged.
u_maxtries	Number of consecutive invalid password attempts after which account will be locked.
u_unlock	Amount of time after which an account locked because of u_maxtries will be unlocked (Tru64 only).
u_expdate	Date account expires (Tru64 only).
u_acct_expire	Account lifetime (HP-UX only).
u_pickpw	Whether user is allowed to select a password.
u_genpw	Whether user is allowed to use the system password generator.
u_restrict	Whether quality of proposed new passwords is checked.
u_policy	Site-specific program used to check proposed password (Tru64 only).
u_retired	Account is retired: no longer in use and locked (Tru64 only).
u_booauth	If > 0, user can boot the system when d_boot_authenticate is true in the system default file (HP-UX only).
u_pw_admin_num	Random number that functions as an initial account password.

All of the available fields are documented on the prpwd manual page.

System default values for protected password database fields are stored in /etc/auth/system/default under Tru64 and /tcb/files/auth/system/default under HP-UX. The values in users' records hold changes with respect to these settings. In addition, these system-wide defaults may be set in the default file:

Tru64: d_pw_expire_warning, the default warning period for about-to-expire passwords.
HP-UX: d_boot_authenticate, which indicates whether the boot command is password-protected or not.

It is not necessary to edit the protected password database files directly. Indeed, the relevant manual pages discourage you from doing so. Instead, you are encouraged to use the graphical utilities that are provided. Doing so is often helpful because these tools describe the various settings in a more understandable form than the corresponding field name alone provides. Nevertheless, there will be times when examining the entry for a particular user is the best way to diagnose a problem with an account, so you'll need to be able to make some sense of these files. We'll consider the most important of them when we discuss password management later in this chapter.

6.1.3 The Group File, /etc/group

Unix groups are a mechanism provided to enable arbitrary collections of users to share files and other system resources. As such, they provide one of the cornerstones of system security.

Groups may be defined in two ways:

Implicitly, by GID; whenever a new GID appears in the fourth field of the password file, a new group is defined.
Explicitly, by name and GID, via an entry in the file /etc/group.

NOTE

figs/armadillo_tip.gif

The best administrative practice is to define all groups explicitly in the /etc/group file, although this is not required except under AIX.

Each entry in /etc/group consists of a single line with the following form:

name:*:GID:additional-users

The meanings of these fields are as follows:

name: A name identifying the group. For example, a development group working on new simulation software might have the name simulate. Names are often restricted to eight characters.
* or !: The second field is the traditional grouppassword field, but it now holds some sort of placeholder character. Group passwords are no longer stored in the group file (and, in fact, they are used only by Linux systems).
GID: This is the group's identification number. User groups generally start numbering at 100.^[5]

^[5] Usernames and group names are independent of one another, even when the same name is both a username and a group name. Similarly, UIDs and GIDs sharing the same numerical value have no intrinsic relation to one another.
additional-users: This field holds a list of users (and, on some systems, groups) who are members of the group, in addition to those users belonging to the group by virtue of /etc/passwd (who need not be listed). Names must be separated by commas (but no spaces may appear within the list).

Here are some typical entries from an /etc/group file:

chem:!:200:root,williams,wong,jones bio:!:300:root,chavez,harvey genome:!:360:root

The first line defines the chem group. It assigns the group identification number (GID) 200 to this group. Unix will allow all users in the password file with GID 200 plus the additional users williams, wong, jones, and root to access this group's files. The bio and genome groups are also defined, with GIDs of 300 and 360, respectively. Users chavez and harvey are members of the bio group, and root is a member of both groups.

The various administrative tools for managing user accounts generally have facilities for manipulating groups and group memberships. In addition, the group file may be edited directly.

On Linux systems, the vigr command may be used to edit the group file while ensuring proper locking during the process. It works in an analogous way to vipw, creating a temporary copy of the group file for actual editing, and saving a copy of the previous group file when modifications are complete.

If your Linux system has vipw but not vigr, chances are that the latter is supported anyway. Create a symbolic link to vipw named vigr in the same directory location as the former to enable the variant version of the command: ln -s /usr/sbin/vipw /usr/sbin/vigr.

Most Unix systems impose a limit of 16 (or sometimes 32)group memberships per user. Tru64 also limits each line in /etc/group to 225 characters. However, group definitions can be continued onto multiple lines by repeating the initial three fields.

6.1.3.1 User-private groups

Red Hat Linux uses a different method, known as user-private groups (UPGs), for assigning user primary group membership. In this scheme, every user is the sole member of a group with the same name as his username, whose GID is the same as his UID. Users can then be added as additional members to other groups as needed.

This approach is designed to make project file sharing easier. The goal is to allow a group of users, say chem, to share files in a directory, with every group member being able to modify any file. To accomplish this, you change the group ownership of the directory and its files to chem, and you turn on the setgid permission mode for the directory (chmod g+s), which causes new files created there to take their group ownership from the directory rather than the user's primary group.

The dilemma for this line of reasoning comes when deciding how group write access should be enabled for files in the shared directory. UPG proponents argue that this needs to be accomplished automatically by using a umask of 002. However, the side-effect of this convenience users not having to explicitly assign write permission to files they want to share means that other files the user creates (e.g., ones in his home directory) will also be group-writeable, a very undesirable outcome for security reasons. The "solution" is to make the user's primary group a private group, to which granting write access is benign or irrelevant, since the group is equivalent to the user.

In the end, however, UPGs are deeply embedded within the Red Hat Linux way of doing things, so administrators of Red Hat systems must learn to live with them.

UPGs are also created by the FreeBSD adduser command.

6.1.4 Dynamic Group Memberships

In most cases, Unix does not distinguish between the two ways of establishing group membership; exceptions are the group ownership of new files and accounting data records, both of which generally reflect/record the current primary group membership. In other contexts for example, file access a user is simultaneously a member of all of her groups: her primary group and all of the groups for which she is listed as an additional member in /etc/group.

The groups command displays a user's current group memberships:

$ groups  chem bio phys wheel

The groups command will also take a username as an argument. In this case, it lists the groups to which the specified user belongs. For example, the following commands lists the groups of which user chavez is a member:

$ groups chavez  users bio

In a few circumstances, the group that is the user'sprimary group is important. The most common example is accounting systems where resource usage is tracked by project or department in addition to user. In such contexts, the primary group is typically the one that is charged for a user's resource use.^[6]

^[6] Solaris provides project-based accounting in another way. See Section 17.3 for details.

For such cases, a user can temporarily change the group designated as her primary group by using the newgrp command:

$ newgrp chem

The newgrp command creates a new shell for this user, setting the primary group to be chem. Without an argument, newgrp resets the primary group to the one specified in the password file. The user must be a member of the group specified as the argument to this command.

FreeBSD does not support changing the primary group and so does not provide newgrp.

The id command can be used to display the currently active primary and secondary group memberships:

$ id  uid=190(chavez) gid=200(chem) groups=100(users),300(bio)

Current primary group membership is indicated by the "gdocSection3Title">6.1.4.1 The Linux group shadow file, /etc/gshadow

On Linux systems, an additional group configuration file is used. The file /etc/gshadow is the group shadow password file. It contains entries of the form:

group-name:encoded password:group-admins:additional-users

where group-name is the name of the group, and encoded password is the encoded version of the group password. group-admins is a list of users who are allowed toadminister the group by changing its password and modifying memberships within the group (note that being so designated does not make them members of the specified group). additional-users is almost always a copy of the additional group members list from /etc/group; it is used by the newgrp command to determine which users can designate this group as their primary group (see below). Both lists are comma-separated and may not contain spaces.

Here are some sample entries from a group shadow file:

drama:xxxxxxxxxx:foster:langtree,siddons bio:*:root:root,chavez,harvey

The group drama has a group password, and users langtree and siddons are members of it (as are any users who have it as their primary group, as defined in /etc/passwd). Its group administrator is user foster (who may or may not be a member of this group). In contrast, group bio has a disabled group password (since an asterisk is not a valid encoding for any password character), root is its group administrator, and users root, chavez, and harvey are additional members of the group.

The SuSE version of the vigr command accepts a -s option in order to edit the shadow group file instead of the normal group file.

On Linux systems, the newgrp command works slightly differently, depending on the group's entry in the group password file:

If the group has no password, newgrp fails unless the user is a member of the specified new group, either because it is her primary group or because her username is present in the additional members list in the group shadow password file, /etc/gshadow.
Because secondary group memberships for file access purposes are taken from the /etc/group file, it makes no sense for a user to appear in the group shadow file but not in the main group file. Omitting a secondary user defined in /etc/group from the shadow group list prevents him from using newgrp with that group, which might be desirable in some unusual circumstances.
If the group has a password defined, any user who knows the password can change to this group with newgrp (the command prompts for the group password).
If the group has a disabled password (indicated by an asterisk in the password field of /etc/gshadow), no user may change her primary group to that group with newgrp.

6.1.4.2 The HP-UX /etc/logingroup file

If the file /etc/logingroup exists on an HP-UX system, its contents are used to determine the initial group memberships when a user logs in. In this case, the additional members list in the group file is used to determine which users may change their primary group to a given group with newgrp. Common sense dictates that the additional members list in the logingroup file be a superset of the list in the corresponding entry in /etc/group.

6.1.4.3 AIX group sets

AIX extends the basic Unix groups mechanism to allow a distinction to be made between the groups a user belongs to, which are defined by the password and group files, and those that are currently active. The latter are referred to as the concurrent group set; we'll refer to them as the "group set." The current real group and group set are used for a variety of accounting and security functions. The real group at login is the user's primary group, as defined in the password file. When a user logs in, the group set is set to the entire list of groups to which the user belongs.

The setgroups command is used to change the active group set and designated real group. The desired action is specified via the command's options, which are listed in Table 6-2.

Table 6-2. Options to the AIX setgroups command
Option	Meaning
`-a glist`	Add the listed groups to the group set.
`-d glist`	Delete the listed groups from the group set.
`-s glist`	Set the group set to the specified list of groups.
`-r group`	Set the real group (group owner of new files and processes, etc.).

For example, the following command adds the groups phys and bio to the user's current group set:

$ setgroups -a phys,bio

The following command adds phys to the current group set (if necessary) and designates it as the real group ID:

$ setgroups -r phys

The following command deletes the phys group from the current group set:

$ setgroups -d phys

If the phys group was also the current real group, the next group in the list (in this case system) becomes the real group when phys is removed from the current group set. Note that each time a setgroups command is executed, a new shell is created.

Without arguments, setgroups lists the user's defined groups and current group set:

$ setgroups chavez: user groups = chem,bio,phys,genome,staff process groups = phys,bio,chem

The groups labeled "user groups" are the entire set of groups to which user chavez belongs, and the groups labeled "process groups" form the current group set.

6.1.5 User Account Database File Protections

Proper file ownership and protection on the us er accounts database files are extremely important to maintaining system security. All of these files must be owned by root and a system group such as GID 0. The two shadow files should also prevent access by anyone but their owner. root may have write access to any of these files.

Apply the same ownership and protection to any copies of these files you make. For example, here is a long directory listing of the various files from one of our systems:

# ls -l /etc/pass* /etc/group* /etc/*shad* -rw-r--r--   1 root     root          681 Mar 20 16:15 /etc/group -rw-r--r--   1 root     root          752 Mar 20 16:11 /etc/group- -r--r--r--   1 root     root          631 Mar  6 12:46 /etc/group.orig -rw-r--r--   1 root     root         2679 Mar 19 13:15 /etc/passwd -rw-r--r--   1 root     root         2674 Mar 19 13:15 /etc/passwd- -rw-------   1 root     shadow       1285 Mar 19 13:11 /etc/shadow -rw-------   1 root     shadow       1285 Mar 15 08:37 /etc/shadow-

We made a copy of the group file (group.orig) which we protected against all write access. The files with the hyphens appended to their name are backup files created by the vipw and vigr utilities. Whatever the specific files present on your system, ensure that all of them are protected properly, and make doubly sure that no shadow file is readable by anyone but the superuser.

6.1.6 Standard Unix Users and Groups

All Unix systems typically predefine many user accounts. With the exception of root, these accounts are seldom used for logins. The password file as shipped usually has these accounts disabled. Be sure to check the shadow password file on your system, however. System accounts without passwords are significant security holes that should be plugged right away.

The most common system user accounts are listed in Table 6-3.

Table 6-3. Standard Unix user accounts
Usernames	Description
root	User 0, the superuser. The defining feature of the superuser account isUID 0, not the username root; any account with UID 0 is a superuser account.
bin, daemon, adm, lp, sync, shutdown, sys	System accounts traditionally used to own system files and/or execute the associated system server processes. However, many Unix versions define these users but never actually use them for file ownership or process execution.
mail, news, ppp	Accounts associated with various subsystems and facilities. Again, these accounts serve to own the corresponding files and to execute the component processes.
postgres, mysql, xfs	Accounts created by optional facilities installed on the system to administer and execute their services. These three examples are accounts associated with Postgres, MySQL, and the X font server, respectively.
tcb	Administrative account that owns the C2-style security-related files and databases on some systems with enhanced security (tcb=trusted computing base).
nobody	Account used by NFS and some other facilities. As defined on BSD systems, nobody traditionally has the UID -2, which usually appears in the password file as 65534=2¹⁶-2 (UIDs are of the unsigned data type: on 64-bit systems, this number may be much larger). System V's nobody UID is 60001. Some systems define usernames for both of them. Inexplicably, Red Hat uses 99 as nobody's UID, although it defines other usernames for the traditional values.

Unix systems are similarly shipped with a /etc/group file containing entries for standard groups. The most important of these are:

root, system, wheel, or sys: The group withGID 0. Like the superuser, this group is very powerful and is the group owner of most system files.
Most systems define a number of system groups, analogous to the similarly named system user accounts: bin, daemon, sys, adm, tty, disk, lp, and so on. Traditionally, these groups own various system files (e.g., tty often owns all the special files connected to serial lines); however, not all of them are actually used on every Unix system.
FreeBSD and other BSD-based systems use the kmem group as the owner of programs required to read kernel memory.
mail, news, cron, uucp: groups associated with various system facilities.
users or staff (often GID 100): Many Unix systems provide a group as the default primary group for ordinary user accounts.

6.1.7 Using Groups Effectively

Effective file permissions are intimately connected to the structure of your system's groups. On many systems, groups are the only method the operating system provides to refer to and operate on arbitrary sets of users. Some sites define the groups on their systems to reflect the organizational divisions of their institution or company: one department becomes one group, for example (assuming a department is a relatively small organizational unit). However, this isn't necessarily what makes the most sense in terms of system security.

Groups should be defined on the basis of the need to share files and, correlatively, the need to protect files from unwanted access. This may involve combining several organizational units into one group or splitting a single organizational unit into several distinct groups. Groups need not mirror "reality" at all if that's not what security considerations call for.

Group divisions are often structured around projects; people who need to work together, using some set of common files and programs, become a group. Users own the files they use most exclusively (or sometimes a group administrator owns all the group's files), common files are protected to allow group access, and all of the group's files can exclude non-group member access without affecting anyone in the group. When someone works on more than one project, then he is made a member of both relevant groups.

When a new project begins, you can create a new group for it and set up some common directories to hold its shared files, protecting them to allow group access (read-execute if members won't need to add or delete files and read-write-execute if they will). Similarly, files will be given appropriate group permissions when they are created based on the access group members will need. New users added to the system for this project can have the new group as their primary group; relevant existing users can be added to it as secondary group members in the group file.

The Unix group mechanism is not a perfect security solution, however. For example, suppose that a user needs access to just one or two files that are owned by a group to which she doesn't belong, and you don't want to make her a member of the second group because it will give her other privileges that you don't want her to have. One solution is to provide a setgid program that allows her to access the needed files; the setuid and setgid access modes are the subject of the next subsection. However, to properly address such a dilemma, you have to go beyond what is offered by the standard Unix group scheme. Access control lists, a mechanism that allows file permissions to be specified on a per-user basis, are the best solution to such problems, and we will consider them in Section 7.4.