In last month's Guru Guidance column, we looked briefly at Linux user accounts in the context of the user authentication process. In this month's column, we will take a look at the fundamental Linux multiuser entity: groups.
In last month’s Guru Guidance column, we looked briefly at Linux user accounts in the context of the user authentication process. In this month’s column, we will take a look at the fundamental Linux multiuser entity: groups.
Groups are the mechanism that Unix systems provide 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 Group ID (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.
The best administrative practice is to define all groups in the /etc/group file.
Each individual entry in /etc/group consists of a single line having the following form:
The meanings of these fields are:
group-name: A name identifying the group. For example, a development group that is working on new simulation software might have the group-name simulation.
“!”: The second field is the traditional group password field. It holds an exclamation point when a group password file is in use (see below), as is usually the case under Linux.
GID: This is the group’s identification number. User groups generally start numbering at 100. Note that usernames and group names are independent of each other, even when the same name is both a username and a group name. Similarly, UIDs and GIDs sharing the same numerical value have absolutely no inherent, system-recognized relation to one another either, although the system administrator may choose to assign them in analogous ways (see the User Private Groups sidebar, pg. 78).
additional users: This field lists all of the users and groups that will have access to this group’s files in addition to those users belonging to the group by virtue of /etc/passwd. (These users do not need to be listed.) Note the correct syntax — usernames must be separated by commas, but no spaces may appear within the list.
Here are some typical entries from an /etc/group file:
The first line defines the chem group. It assigns the group identification number (GID) 200 to this group. Linux will allow all members of group 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 have access to the bio group’s files, and root can access files of both groups.
Since it is an ASCII text file, you can edit the group file with any text editor. If you edit the file manually, it’s a good idea to save a copy of the unedited version so you can recover from errors:
# cd /etc
# cp group group.sav
Save a copy of the current file
# chmod go = group.sav
Protect the copy (or use a umask that does this)
# emacs group
If you want to be even more careful, you can copy the password file again, to something like group.new and edit that, renaming it only when you’ve successfully exited the editor. This will save you from having to recopy it from group.sav on those rare occasions when you totally munge the password file in the editor. Alternatively, you can use the vigr command to facilitate the process, allowing it to be careful for you. This command is analogous to the familiar vipw command used to edit the password file.
Note: If your system has the vipw command 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
vigr invokes an editor on a copy of the group file (generally named /etc/ gtmp on Red Hat systems or /etc/group. edit on SuSE systems). The utility also provides a locking mechanism to prevent simultaneous editing by two different users. The 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/group and stores a copy of the previous group file as /etc/group.OLD (Red Hat) or /etc/ group- (SuSE).
Linux systems are similarly shipped with a standard /etc/group file, which holds entries for standard groups. The most important of these groups are:
* root: the group having GID 0. Like the superuser, this group is very powerful and it is the group owner of most system files. On some systems, only members of group 0 may use the su command.
* Most systems define a number of system groups, analogous to the similarly named system user accounts: bin (1), daemon (2), sys (3), adm (4), tty (5), disk (6), lp (7), and so on. Traditionally, these groups owned 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 Linux system.
* mail (12), news (13), uucp (14): groups associated with various system facilities.
* users (100): SuSE Linux provides this group as the default primary group for ordinary user accounts. Red Hat Linux uses user-private groups instead (see the User-Private Groups sidebar).
The Group Shadow File
The file /etc/gshadow is the group shadow password file. It is similar to the shadow password file in that it stores sensitive group-related information and settings in a file that is inaccessible to anyone but root.
The group shadow file contains entries of the form:
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 to administer 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 should be a copy of the additional group members list from /etc/group; it is used by the newgrp command (see below). Both lists are comma-separated and may not contain spaces.
Figure One shows some sample entries from a group shadow file.
Figure One: Entries of a Group Shadow File
The group drama has a group password, and users langtree and siddons are members of it (as well as any users having 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 defined as additional members of the group.
The gpasswd command is used to modify entries within this file, and the command takes the desired group name as its argument. Without any options, it allows you to set the password for the specified group.
The -a and -d options allow you to add and delete (respectively) a user as an additional member of a specified group. For example, issuing the following command will add user chavez to the drama group:
# gpasswd -a chavez drama
The -A and -M options are used to specify the list of group administrators and additional group members in the group shadow file. For example, the following command designates users root and nielsen as group administrators for the bio group:
# gpasswd -A root,nielsen bio
The list of users specified as the argument to either option must be comma-separated and must not contain any internal spaces. Note that these options replace the current settings in /etc/gshadow; they do not add additional users to the existing list.
|Figure Three: Managing groups with the KDE User Manager.|
Aside from issuing commands, users may also be added to secondary groups using the various graphical user account administration tools. Figure Three illustrates the tools that are provided by the KDE User Manager application for managing group memberships.
In the figure, we are about to add user chavez to the chem group.
Finally, some versions of the vigr command accept a -s option. This lets you edit the shadow group file instead of the editing just the normal group file.
Dynamic Group Memberships
In most cases, Linux does not distinguish between these two types of groups (exceptions are group ownership of new files and accounting data). A user is simultaneously a member of all of her groups — that is, her primary group and all of the groups for which she is listed as an additional member in /etc/group — for system access purposes by default. The groups command displays a user’s current group memberships:
chem bio physwheel
The groups command will also take a username as an argument; in this case, it lists the groups to which user chavez belongs:
$ groups chavez
A user can change the group that is designated as her primary group with the newgrp command:
Newgrp creates a new shell for this user, setting the primary group to be chem. Issuing the newgrp command without any argument will reset the primary group to be the one specified in the password file.
In general, the newgrp command works slightly differently, depending on the group password status:
* If the group has no password, then the user must be a member of the specified new group, either because it is her primary group or her username is present in the additional members list in the group shadow password file, /etc/gshadow. If she is not a member of the specified new group, she will not be allowed to change groups with newgrp.
* If the group does have a password defined, then any user who knows the password can change to this group using newgrp (the command will prompt the user for the group password).
* If the group has a disabled password (indicated by an asterisk in the password field of /etc/gshadow), then no user may change her primary group to that group with newgrp. This setting effectively disables newgrp with respect to this group.
The id command can be used to display the currently active primary and secondary group memberships, as can be seen in Figure Two.
Figure Two: Active Primary and Secondary Group Memberships
Using Groups Effectively
Since groups are a primary means of allowing and preventing access to system resources, system security depends very heavily on having properly defined groups.
Some sites define groups to reflect their underlying organizational structure, for example, making each department or other unit its own group. However, this approach isn’t necessarily what makes the most sense in terms of system security.
Groups should be defined solely on the basis of the need to share files and of preventing unwanted access to files. When looked at in this way, organizational units may often need to be combined or split up when they are mapped to groups, sometimes drastically cutting across or around real-world organizational divisions. In fact, Linux groups need not mirror “reality” at all if that’s not what security considerations call for.
Group divisions are most often structured around projects; people who need to work together, using some set of common files and programs, will become a Linux group. Users may own the files they use most often or a group administrator may own all of the group’s files.
In any case, shared files are protected in order to allow appropriate access by all group members, and all of the group’s files can exclude non-group member access without affecting anyone in the group. Users working on multiple projects are simply made members of all of the relevant groups. It’s this kind of flexibility that makes Linux such an effective multi-user system.
See you next month.
Red Hat Linux uses a different method for assigning user primary group memberships known as user-private groups. Under this scheme, every user is the sole member of a group having the same name as his username and whose GID is the same as his UID. Users can then be added as additional members to other groups as needed.
The reasoning behind this approach is designed to make project file sharing easier and goes something like this:
* 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. So you change the group ownership of the directory and its files to chem, and 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. Quoting the official Red Hat description of UPGs: “But the new file needs to be mode 664 for another user in the…group to be able to edit it. To do this you make the default umask 002.” [Red Hat Linux 6.1: The Official Red Hat Linux Reference Guide]
* However, this tactic introduces another problem: such a umask means that other files the user creates-such as ones in his home directory — will also be group-writable, 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).
For me, the flaw in this way of thinking is assuming that the umask is the only way to assign group write access to a new file. Clearly, the user could also use the chmod command to accomplish the same effect — and he would retain the option of doing so or not. In general, I rate the minor inconvenience from write-protected files as clearly a lesser evil than the potential security problems running with a umask of 002 entails. (For example, what if the user changes his primary group with newgrp?)
Having said this, UPGs are deeply embedded into Red Hat Linux, and system administrators of those system will have to learn to live with them.
Æleen Frisch is the author of Essential System Administration. She can be reached at firstname.lastname@example.org.