User-Level Management
Of Unix Group Membership
ABSTRACT
We describe the design and implementation of a soft-
ware suite, GrpAdmin, that allows unprivileged users to
manage Unix group memberships. We begin by enumerating
common problems associated with traditional group man-
agement. We then show how GrpAdmin alleviates these
problems. The final section notes the effects, many of
them sociological, anticipated during introduction and
deployment of the new software.
1. Introduction and Problem Statement
Unix groups, while a powerful concept, are subject to two annoy-
ing limitations. First, all group information has traditionally
been stored in a single file, /etc/group or equivalent. The abil-
ity to change /etc/group confers all-or-nothing powers of group
manipulation -- either anything can be done to all groups or
nothing can be done to any group. Thus, for security reasons,
group management responsibility has been concentrated in the
hands of a relatively small number of privileged people. This
inability to directly delegate responsibility for group manage-
ment to the people directly involved with the group (e.g., mem-
bers of project-related group) causes increased communication
overhead, distractions, interrupts and occasional frustrating
delays.
A second problem is the limit imposed by Unix on the maximum num-
ber (usually 16-32) of groups associated with an individual or
process. This limit intrudes when extensive or fine-grained
group-based file sharing is required. A typical example occurs
when instructors or TAs must be members of a large number of
class-specfic groups. Since changing group memberships "on the
fly" is difficult or impossible, it may be necessary for those
individuals to sacrifice other group memberships in order to
accomodate the addition of the class groups.
Yet another limit on group memberships is imposed by the ubiqui-
tous presence of NFS. The NFS RPC protocol can truncate group
access credentials to even fewer than the number supported by the
underlying OS. Users may encounter problems accessing NFS
mounted files by virtue of being in too many groups on one
machine or in too few on another.
In the following sections we describe GrpAdmin, a software suite
that eases these problems by moving toward a role-based autho-
rization model while maintaining existing CSE security and admin-
istrative procedures.
2. Allowing Users to Manage Group Memberships
The primary abstractions maintained by GrpAdmin are those of
group ownership and membership. A group owner can add or delete
group members or other owners of that group. A group member can
define what groups are initially associated with that person's
processes at login time.1 Note that owners and members can only
manipulate ownerships and memberships. Creation or deletion of
an entire group is reserved to a set of administrative users. The
rights associated with each type of user are summarized in Table
1.
+----------------------------------------------------+
| Table 1 |
| Group Management Rights By Role |
+--------------++------------------------------------+
| Operation || Privilege Level |
+--------------++-------+-------------+--------------+
| Add/Delete ||Admin. | Group Owner | Group Member |
+--------------++-------+-------------+--------------+
|Entire Group || Yes | No | No |
| Ownership || Yes | Yes | No |
| Membership || Yes | Yes | Delete self |
|"Login Group" || Yes | No | Yes (self) |
+--------------++-------+-------------+--------------+
The rules governing ownership and membership are enforced by
GrpAdmin, a suite of programs and libraries that can be loosely
categorized as:
1. A database schema and set of access routines that define
the relationship between groups, owners and members and
provide secure, authenticated access to manipulating those
relationships.
2. Several user interfaces (command line, X-Windows and Web)
to group management operations.
3. Maintenance scripts that transparently incorporate database
information into existing system administration procedures.
4. A shell-oriented program allowing users to dynamically
exercise group-based file access rights without encounter-
ing OS limitations.
In the following sections we provide a general overview of the
design and implemention of each of these items and how they
inter-operate, both within themselves and with existing CSE group
administration procedures.
2.1. Existing Procedures
The GrpAdmin software was designed to have minimal impact on
exisiting administrative procedures. It is thus instructive to
review what these procedures are.
For security reasons, group membership information is contained
in a master group file, access to which is limited to a small set
of people. All group updates must be filtered through this band
of people who perform changes using a text editor.
A complication to this scheme is that (apparently for historical
reason) not all group definitions cross CSE system administration
boundaries. Some groups appear only on research machines, others
only within the instructional domain. Thus there are actually
two primary group files, one for each administrative scope. This
arrangement has the unfortunate side effect that changes to the
many truly "global" groups require separate edits to both primary
files.
Individual SAs periodically retrieve a copy of primary file for
their administrative scope. Further processing is then performed
to add (or delete) system-specific groups depending on the "best
practices" implemented by each SA.
The final group files for each domain/system pair are then dis-
tributed to the machines that use them. The manner of this dis-
tribution is again SA-dependent: SUP, rdist, YP maps, etc.
GrpAdmin's emphasis is on the first two aspects of this situa-
tion: removing the group update bottleneck and eliminating the
need to "edit a file" to effect changes.
2.2. Group Database Design and Access
GrpAdmin uses a POSTGRES 6.5.3 database to maintain information
related to group ownership and membership. Using a database pro-
vides several immediate advantages in terms of concurrency, atom-
icity, consistency, crash recovery, network communication and
accessibility from a wide variety of programming languages (e.g.,
C, PERL, Tcl/Tk). The DB organization itself is extremly simple.
A single database, unixgroups, consists of three main tables
given in Figure 1.
TABLE unix_group (
groupname text unique,
groupid int4 unique,
scope int4
);
TABLE group_owner (
username text,
groupname text
);
TABLE group_member (
userid text,
groupname text,
logingroup bool,
scopeid int4
);
Figure 1: Unix Group Database Structure
Only the scope and logingroup attributes require further comment.
A group's scope controls the appearance of that group within a
administrative domain, as mentioned in Section 2.1.. Current
scopes are research and global. As of January 2001, the instruc-
tional administrative domain has been retired; the group file
used on instructional machines is the same as that used on
research machines. The logingroup attribute determines which
groups are associated with a user at login time, up to a maximum
of 13 groups. Thirteen is the limit since one logingroup slot is
always taken by the user's /etc/passwd group and two others may
be taken up by an AFS pag. These three slots plus the 13 discre-
tionary groups total 16, the maximum number of groups supported
by NFS/RPC.
Access to the GrpAdmin database is provided by a common library
module used by all higher level interfaces. This module
(grpdbaccess.tcl) authenticates2 the user and performs authorized
operations given in Table 1 in a manner similar to a trusted
suid-style program. It is worth noting that the authority infor-
mation is, in general, embedded in the GrpAdmin database itself.
The exception to this rule is administrative ("super-user")
access. Administrative authority is derived from Kerberos
authentication: an authenticated user principal matching */root
or */grpadmin is considered to be a "super-user" and may perform
any operation.
2.3. User Interfaces To Group Administration
There are three users interfaces to GrpAdmin: command line, X-
Windows and Web. For practical purposes the latter two are sim-
ply eye candy wrapped around the functionality provided by the
command line interface and are not described further. The com-
mand line program, grpadmin, supports the operations listed in
Figure 2, either as arguments or as lines read from standard
input in interpreter mode. Operations not implemented by grpad-
min require intervention by the database owner.
creategrp <grpname> [-grpid <number>] [-owners <user-list>] [-scope <name>]
Create a new group with the given unique name. A numeric
gid will be automatically assigned unless -grpid is given.
A list of initial owners may be specified. The default scope of
the new group is global.
deletegrp <grpname>
Delete a group, along with all its owners and members.
addmember <grpname> -who <user-list>
Add a list of users to a group membership.
delmember <grpname> -who <user-list>
Delete a list of users from a group membership.
addowner <grpname> -who <user-list>
Add a list of users as owners of a group.
delowner <grpname> -who <user-list>
Remove a list of users from group ownership.
deluser <user-name>
Delete a single user from all group membership and ownership.
addlogin <grpname> -who <user-list>
Add a group as logingroup for the specified users.
dellogin <grpname> -who <user-list>
Delete a group as a logingroup for the specified users.
showgrps <grpname-list>
List the gids and scopes of the given groups.
showmembers <grpname-list>
List the members of the given groups.
showowners <grpname-list>
List the owners of the given groups.
listugrps <user-list>
List the group memberships of the given users.
listowned <user-list>
List the groups owned by the given users.
renamegrp <grpname> -to <newgrpname>
Give an existing group a new name.
Figure 2: Group Administration Commands
2.4. Operation and Maintenance
As mentioned above, one of GrpAdmin's goals was to be compatible
with existing group maintenance procedures. To that end, scripts
were written that:
+o create the entire unixgroups database from existing scope-spe-
cific primary group files
+o periodically poll the database for changes and create the
appropriate group primary files from the database contents
The first item is interesting primarily from the standpoints of
disaster recovery and experimentation with new implementations.
The second allows continuing the tradition of SA-specific changes
to group files and methods of distribution. It also serves the
purposes of tracking group changes and debugging. All updates to
the database are recorded, including the identity of the initia-
tor, SQL commands executed, etc. Resulting group files are
archived using RCS, as is the update log itself.
2.5. Exercising Group Membership
The final component of GrpAdmin is a program, chgrpsh, that
allows users to exercise group membership rights without encoun-
tering OS limitations on the number of process groups or waiting
for group file changes to propagate. Chgrpsh is a suid-root pro-
gram accepting arguments of the form:
chgrpsh [ [+|-]<group-name> ] [command string]
The program creates a new process group set fro the current one
by first removing all groups preceded by a '-', inserting all
groups preceded by a '+' and then executing the given command as
the invoking user; if no command is given, the user's shell is
spawned. Chgrpsh determines which groups it is permissible to
join by consulting, in order, the local /etc/group file, a local
copy of /etc/group.all3 and finally the group database itself.
3. Implications of Deployment
Deployment of GrpAdmin will affect three classes of people: sys-
tem administrators, current group maintenance personnel (i.e,
support@cs) and the vast horde of ordinary users. Each of these
are dealt with in approximately increasing order of impact.
3.1. System Administrators
System administrators should notice minimal changes. GrpAdmin
was specifically designed to leave current distribution proce-
dures intact. The DB is populated from existing primary group
files with no data added or subtracted. Updated primary files
derived from DB content are exactly the same format as current
files. The only anticipated differences are that the new primary
files will be created in a different location and that an extra
file, /etc/group.all, will be copied to individual machines.
3.2. support@cs
The people who currently maintain group information will benefit
considerably from using GrpAdmin. It will no longer be necessary
to edit one or more files to make changes. Using one of the con-
nection-oriented GrpAdmin UIs should reduce context switching,
eliminate the need for determining exclusive access to files and
sending change notifications to SAs, etc. But, most importantly,
support personnel will now longer need to be involved in every
change to group information.
3.3. Ordinary Users
This is the most difficult class of people to deal with but con-
vincing them to use GrpAdmin will pay the greatest dividends in
terms of reducing support work load and increasing user satisfac-
tion.
Primary obstacles that must be overcome are:
+o Simple inertia. People are used to sending group change
requests to support@cs which is a relatively simple procedure
for them. Introduction of GrpAdmin may initially be viewed as
a reduction in service. With luck this attitude can be over-
come by...
+o Education. This effort encompasses two issues. First, simply
learning to employ one of GrpAdmin's user interfaces to make
group changes. The selling point here is that changes are for
practical purposes immediate. This alone will be sufficient to
convince some people to use GrpAdmin. The second education
issue is more far-reaching since it is procedural rather than
applicative. That is, convincing people that GrpAdmin offers a
better operational paradigm: instead of "service" one has
"power" and its attendant responsibility.
An example of what this means is the proposed treatment of
class groups: At the start of a quarter, the instructor for
each class is made the owner of any class groups. From that
point forward, all group changes are the responsibility of the
instructor. Although the instructor will be required to do
slightly more, the increased control and decreased response
time should compensate for any perceived inconvenience. Pro-
ject groups should be treated similar manner by determining a
group owner and allowing him/her to manage membership in the
group. The educational process will terminate in...
+o Enforcement. Basically this means at some point in time, sup-
port@cs will refuse to execute group change requests with the
exception of creating or deleting groups.
Appendix A: Authentication And Authorization Details
Authority to change the database is enforced by the user inter-
face based on the following simple rules:
1. A "super-user" can make any change, including creating a
new group or deleting an existing one.
2. The owner(s) of a group can add or remove owners of the
group.
3. The owner(s) of a group can add or remove members from the
group.
4. A group member can remove him/herself from the group.
5. A group member can toggle the logingroup status of a par-
ticular membership within the 13 group limit noted above.
The authenticity of the user is determined by acquiring a Ker-
beros ticket for the DB backend (postgres_dbms) and peforming a
mutual authentication that is part of the standard DB connection
protocol. All things being equal, the authentication will succeed
but a working connection will be rejected by the DB. Instead, it
is the user interface that "owns" the unixgroup database and sep-
arately authenticates itself to the backend as principal grpadmfe
using a Kerberos keytab readable only by itself. It is this con-
nection that is used for queries and updates.
This somewhat convoluted procedure (which requires changes to
standard POSTGRES libraries) was developed for two reasons.
First, the POSTGRES backend uses its own, separate /etc/passwd
equivalent for authorization purposes. Propagating individual
users into the DB's authorization apparatus would become yet
another Thing That Must Be Taken Care Of. Additionally, POSTGRES
allows only table-level, not row-level, ownership. Allowing
individual users direct update access to the DB would have
required considerable complication in the DB design.
Appendix B: Further Enhancements
It is clear that numerous functional enhancements are possible
and we list two of them here in no particular order. None of
them present overwhelming technical difficulties. But it was not
deemed prudent to expend effort on any of them until the value
and utility of the basic mechanisms were determined.
+o Allowing ordinary users to create groups, using a cre-
ate_groups table as the basis of authorization.
+o Enabling Samba servers to make use of the additional group
information available in /etc/group.all and the DB.
+o It is interesting to speculate on whether/how NT groups could
be managed in a similar manner.
-----------
1 These statements apply only to membership in dis-
cretionary (/etc/group) groups; a user's login
(/etc/passwd) group is not considered discretionary.
2 A detailed description of authentication proce-
dures can be found in Appendix A.
3 This file is a "cache" of the database contents
and is created as part of the operations procedures
mentioned in Section 2.4.. Due to the various limita-
tions on number of process groups, the /etc/group does
not contain entries for all of user's group member-
ships.