Differences between revisions 26 and 27
Revision 26 as of 2011-02-21 01:45:46
Size: 11264
Editor: ?KarlOPinc
Comment: Remove incomprehensable sentence.
Revision 27 as of 2011-04-26 20:34:06
Size: 11072
Editor: ?skizzhg
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
##TRANSLATION-HEADER-START
||<tablestyle="width: 100%;" style="border: 0px hidden">
~- [[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[it/UserPrivateGroups|Italiano]]-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]||
##TRANSLATION-HEADER-END
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[it/UserPrivateGroups|Italiano]]-~

Translation(s): English - Italiano


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.

Debian has been using (creating) user private groups by default almost from the beginning. However, did not fully enable it appropriately on newly installed systems since release 2.2. The central umask adjustment for UPGs from login.defs got lost with the inclusion of PAM, and this facility was only reintroduced and re-enabled with libpam-umask in release 6.0 (Squeeze).

Introductory User Information (->for inclusion as install-time help)

It is easy for multiple users to collaborate on a debian system.

Keep in mind that access permission to a file always depends on the permissions of the file itself and the permissions of the directory path to it. Newly created files in Debian are by default readable for whoever has access to them, just as paper files are, but not writable. If you don't want others to read your files, keep them in a private/ subdirectory. The path into your home directory is not restricted, just as the path others can take to ring your bell at home is not restricted. As a matter of fact, you may post some files on your door for others or to read. For example many programs read config files that you deposit in your home path. And fellow users can drop files (for you personally) in your ~/incoming/ directory.

All this works because by default newly created users have a primary group that is private; it is a group which has no other members. 1 This allows the default permissions to grant write access to the group associated with newly created files because, by default, the group associated with a file that a user creates is the user's private group (UPG) and so no one but the creating user will have write permission. Each user's files remain secure from tampering. Except that is, if the file has been created in a directory setup to share it's content with group members...

Directories configured to share content with a group, directories with the setgid bit set, are shared work spaces. (That, again, are readable by everyone.) All members of the group associated with such a directory can create, and write to, files in the directory. The setgid bit means that all files created in the directory will be associated with the user who created the file and the group associated with the directory. The result is that all members of the group can work on the files in such a directory. Other than that, setgid directories work just like home directories. So, for example, if a file should be readable only by group members put it into a private subdirectory!

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. However, the default on Debian systems was for some time 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 disable umask all particular umask settings for specific shells, display managers, etc., and to use libpam-umask to set it centrally. For libpam-umask append the following line 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

  • Choose a group name for your project. Use addgroup (the "addgroup group" syntax) or vigr to create the group.

  • Decide who is to collaborate and use adduser (the "adduser user group" syntax) or vigr to grant the collaborators' usernames membership in the project's group. Note that group membership is computed at login so each user must re-login.

  • Create a directory (or multiple directories) where the collaboration is to take place. The project directory must be located in a directory to which all project members have directory traversal access. (I.e. project members must have execute permission (x) on the containing directory and all it's parents.) The /srv directory may be a good choice of parent directory. See the Filesystem Hierarchy Standard.

  • Grant permission on the project's directory (thedir) to the project's group (thegroup) with the following commands:

chgrp thegroup thedir
chmod g=rwxs thedir

You could patch adduser to create appropriate directories automatically, and create subusers and subgroups manually, e.g. to use them for running testing specific applications.

For each <groupname> create:

/home/group/<groupname>           (world readable, sgid writeable for members of the group)
/home/group/<groupname>/private   (readable (and writeable) only for members of the group)
/home/group/<groupname>/incoming (world writeable, sticky files, non-public (not browsable) filenames)

For each <user>: 

/home/<user>/private            (readable (and writeable) only for the user)
/home/<user>/incoming           (world writeable, sgid, sticky files, non-public (not browsable) filenames)


Whoever wants to make the homedirs (/home/<user>) non accessible, needs to introduce a separate place for shares:

/home/share/<user>              (rw for the user and its XDG_PUBLICSHARE_DIR
(However this means user's homedirs would behave differently from groupdirs and the UPG usage scheme.)

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

  1. The primary group of the user has the same name as the user, and the gid equals the uid. Because the gid is listed with on the line that defines the user in /etc/passwd the user is not explicitly listed as a member of the group in /etc/groups. (1)