User Private Groups - Sharing directory content with a group

User private groups is a system configuration idiom which allows users to collaborate by granting shared access to a directory and its content. Access is controlled by associating each collaborative project team with a Un*x group and then granting Un*x group membership to the userids of the designated project members.

Unlike RedHat systems Debian systems are not pre-configured to support user private groups, however it is a matter of a single system-wide change to enable user private group support.

CAUTION

Although the user private group idiom configuration described herein is secure on a "stock" Debian system, if there is such a thing, making the changes described herein could highly compromise your system's security. Everything depends on your system's configuration. Your choice of filesystem may affect the behavior of the setgid bit as applied to directories. Installed packages may alter system configuration, as may other system administrators. Users may modify their default umask. All of these factors affect the availability of the user private group idiom.

You can be confident that the user private group system will work on a Debian system with the default filesystem type choice, only the base packages installed, and no per-user or system-wide customization; beyond that you're on your own.

Enabling User Private Groups

The user private group idiom requires that the default group permissions be read/write with execution allowed. The default on Debian systems is to grant groups read-only access with execution allowed.

The default permissions, which take effect when a file or directory is created, is controlled via the process' umask. There are various ways to change the default umask, the most elegent is probably to use libpam-umask. Append the following lines to /etc/pam.d/common-session:

# Enable the user private groups idiom to allow collaboration based on group membership.
pam_umask.so silent usergroups

Security Considerations

Granting read/write permissions to groups could result in insecure home directories. If two users both have the same primary group then each user could read and write the other's private files. (Recall that the primary group is the group given by default to newly created files and directories.) The user private group idiom gets it's name because each user is assigned a unique primary group, a group which to which only the user belongs. Therefore, by default, the files created by each user are associated with a group to which only the user belongs so it does not matter that the default group permissions are permissive.

Note that the "default" Debian behavior is to create a new group each time a new userid is created, and to have that new group be the userid's primary group. Hence the stage is set to enable the user private group idiom by changing the system-wide default umask.

Using User Private Groups

chgrp thegroup  thedir
chmod g=rwxs thedir

How It Works

Setting the setgid bit (chmod g+s) on a directory changes the group associated with files or subdirectories created within the parent. Instead of the usual behavior, which associates the processes' primary group with new files and subdirectories, the group of the parent directory is used. Hence the default behavior is to associate the project's group with all new files and directories. Because all project members are in the project's group they have read/write access to all files and can traverse all subdirectories. Further, because the system's umask gives groups all permissions and because group members have read/write access to the project directory and to subdirectories, project members can both create new files and subdirectories and change file permissions -- including granting execute permission to files.

The setgid bit on a directory also causes all newly created subdirectories to have their setgid bit set, which automatically extends the above properties downward throughout all the project's subdirectories.

See Also