Translation(s): English - Italiano

(!) ?Discussion


User Private Groups - Sharing directory content with a group

User private groups (UPG) 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. Once enabled system wide, and set up for any given project, it requires no action on the part of the end-user to work as expected. Files and directories can be created, modified, and deleted, and (for the most part) have their permissions modified as usual, whilst being shared with other group members and protected from non-members.

(Unlike RedHat systems) Debian systems prior to release 6.0 (Squeeze) are not pre-configured to support user private groups; in this Debian had followed the historical Unix practice. However it is a matter of a single system-wide change to enable user private group support.

CAUTION

Those running Debian systems older than release 6.0 (Squeeze) may need to consider this 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, and how permissions and group ownership has already been set on existing files and directories. Your choice of filesystem may affect the behavior of the setgid bit as applied to directories. Installed packages may alter the system configuration, as may other system administrators. Users may modify their default umask and change the group ownership and permissions of existing files or directories. All of these factors affect the availability of the user private group idiom and, more significantly, the security of the system in place after enabling user private groups.

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. Having said all that, the user private group idiom can be a good choice (v.s. ACLs) because it uses the familiar, basic, Un*x permission system to provide a secure way to share files that is easy to enable and administer and is transparent when it comes time to use the shared storage.

Enabling User Private Groups

As of Debian 6.0 (Squeeze) user private groups are enabled by default. Those running older releases will need to enable 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 elegant 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.
session required      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' "real" 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.

When User Private Groups Cannot Be Used

User private groups cannot be used when association with a group is required for another purpose, e.g., content served by a webserver is expected to be associated with the www-data group. In these cases ACLs must be used to share files and directories.

See Also