Strategies For Setting Up Groups On Unix Systems

A Unix group is not a political entity in your company, it should reflect a set of users with a particular access need.  For example most Linux systems set up PPP to run suid root.  But the safer method is to create a group "modemusers" and add all users that are allowed to access the modem.  Then make the pppd (and related programs) group "modemusers" and add group execute (and read for script files).  (Actually today's system will usually use PAM to support modem use without the need to create a new group.  But it's still a good example!)

(Note most systems only provide a few columns for the group name on "ls -l" listings, so it pays to keep user and group names short!)

Work groups are people with common access needs.  For instance all web authors that need permission to modify the company web site's contents, or all the developers working on a software project.  Rather than have each user have some or all project files in their own directories, you would want to create a project directgory that all members of that work group have access to (while blocking access for non-members).

Suppose you want to have several web site maintainers ("web authors") with access to modify your web site, conveniently already in a single directory (such as "/var/www").  You can create a group "web", add all web authors to it, and make files in your website document rw  ¹  by group web.  (Web documents should also be readable by everyone.)

This use is supported by additional features, the sgid permission on directories that causes new files and subdirectories to "inherit" the group of the parent directory, regardless of the current group of the user creating the file.  (After all, a given person may have different "roles" in the company and in general cannot be counted upon to use "newgrp" command every time.)  Another feature is the "text" (or "sticky") bit on directories that prevents anyone except the owner to delete or rename the files within.  Depending on your policies you may or may not want that protection; It makes sense to allow any web author to rename files in the web site.

In a workgroup environment the administrator sets the group of a directory (containing that workgroup's files) to the name of that group, say "foo".  Then the sgid bit and the sticky bit are set on the directory (say "/projects/foo").  Add all users of that workgroup as members of the unix group "foo".

One problem remains to be addressed for work groups.  How can you make sure newly created files and sub-directories in the work group will have the correct permissions, usually read,write for both the owner and group, and read for others.  (directories must additionally have the execute ("search") permission for everyone.)  Traditionally that is done by setting the umask value to "002".  ²   However that is not an appropriate setting for files created outside of the work group!  (A secure setting for umask is typically "022", "027", or ""077".)  Rather then force the use of insecure umask values, the modern solution is to use ACL (Access Control List) features to over-ride the umask setting on a per-directory basis.  (See the man pages for ACL, setfacl, getfacl, and mount.)

The result is that as a user edits and creates files in the workgroup directory "/projects/foo", the resulting files will be set to "foo" and other members of "foo" will have rw access to the files.  The great part is that with this setup, if the user is also a member of some other workgroup and does a cd to that workgroup's directory (say "/projects/bar"), the files created there will be rw by that workgroup's group ("bar").

In an academic setting (my turf), every student is put into a separate group (which by the way is the default for most Linuxes).  I modify this to add myself as the only other member of those groups.  Then set umask to 027 so that new files can be accessed by the owner and group only (that is, me and that student).  ³ 

Groups can be use to allow easy group communications.  I remember with older Unixes I've used that the /etc/group group names could be used with mailx to send email to all members of that group.  While I doubt that would work today, it shouldn't be at all difficult to write a small shell or perl script for this:

        $ mailx `group-members web`

or

        $ group-mail web

where "group-mail" is a wrapper script the invokes your favorite email client with the members of the named group as arguments.  This sort of thing can be used for "write" and other communication tools too.

Linux (and Unix) support a global login script and a per user login script, but not a per group login script.  However, if you setup your groups right you can create a directory (in /etc?) to hold login scripts per group (each script is named for the group, e.g., "web").  It is not too difficult to add a bit to the global login script to extract the list of groups the current user belongs to (see the Linux groups command), and for each one run the appropriate group login script.  So you can create groups for sets of users that need similar environment settings.  (Note this doesn't work as well as you might hope!  If some of the groups have incompatible settings the last group script to run wins.  So run the user's primary group script last.  For example:  web author's umask should be 003, but the same person creating other documents in their home directory might need a umask of 077.)

For a large organization it is a lot of work to maintain all the groups!  Imagine controlling access per application by using groups:  You need to create one group per controlled application and continuously add and remove users from these groups.

To overcome some of the shortcomings of groups for the corporate environment, Unix and Linux use ACLs⁴ which allows individual users to be granted permissions on files and on directories, as well as the ability to over-ride umask on directories.  With ACLs any user or set of users can be given permission on a file or a directory (and ACLs inherit to sub-directories) without setting up any additional groups.  You might consider setting up ACLs instead of trying to fine-tune the groups.

Group "nobody" and user "nobody", as well as other predefined user and groups, are used in various server programs.  Most server programs must be run initially as root (usually in order to "listen" on well-known ports, or to use other protected resources).  But if the service had any exploitable security hole some evil person might gain root privileges on you system.  The common solution is to start the service as root, obtain privileged resources, then create a child process that does the actual work as a different, unprivileged user.  The original process usually dies.  Common examples of services that work this way include Apache (httpd) and mySQL.  So you often have a need for a plain ol' user account and group for such services.

On Unix platforms it is common to use either user "nobody" or a special user account created expressly for that purpose (with login disabled for that account), and group "wheel".  On Linux group nobody is usually used instead of wheel (which is used for a different, security related purpose on Linux).

Note it is probably safer and really just as easy to use a separate group and user for each service.  For example if httpd must update a file (such as "htpasswd" files) from a CGI program, then the file must be read/write for the user (or less often group) that httpd runs as.  If you use "nobody" then you end up granting privileges to that user.  Now if some other service also runs as user "nobody", some evil person might be able to modify your htpasswd file (used for secure web site via http authentication protocols).

Take a look at a typical /etc/group file.  There are many pre-defined groups listed.  These are for various specific services (e.g., "adm"), plus some standard groups such as bin that most commands are associated with.  You should not add other members to these groups!  Doing so give no benefit to those users and could affect system security and stability.

However, some pre-defined groups are meant to have additional users added.  For example group wheel on BSD and Linux systems, and groups staff and sysadmin on Solaris.  On Debian-based Linux systems, many access controls are determined by group membership.  For example only members of the "plugdev" group can mount or umount removable media (disks, flash drives, CD-ROMs, etc.)  Such group membership can contol access to modems and NICs, printers, and so on.

Don't remove predefined groups (and users).  nor add new members to .  Make sure login is disabled on all those pre-defined user accounts except root (try using /usr/bin/false or /sbin/nologin for the account's shell).  When adding a new service, configure that service to use new user and group ids, not "nobody" or other pre-defined groups.  Finally remember that groups should reflect a set of users with common access needs.