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
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 "
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
ls -l" listings, so it pays to keep user and group names
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 "
You can create a group "
web", add all web authors
to it, and make files in your website document
(Web documents should also be readable by everyone.)
This use is supported by additional features,
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 "
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 "
sgid bit and the
bit are set on the directory (say "
Add all users of that workgroup as members of the unix group
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
Traditionally that is done by setting the
However that is not an appropriate setting for files created outside
of the work group!
(A secure setting for
umask is typically
027", or ""
Rather then force the use of insecure
the modern solution is to use
ACL (Access Control List) features to
umask setting on a per-directory basis.
(See the man pages for
ACL, setfacl, getfacl, and
The result is that as a user edits and creates files in the workgroup
the resulting files will be set to "
and other members of "
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
to that workgroup's directory (say "
the files created there will be
by that workgroup's group ("
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.
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`
$ group-mail web
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 "
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
to hold login scripts per group (each script is named for the
group, e.g., "
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
and for each one run the appropriate group login
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.
umask should be
but the same person creating other documents in their home
directory might need a
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
which allows individual users to be granted permissions on files and on
directories, as well as the ability to over-ride
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
nobody" and other Pre-defined Groups
nobody" and user "
as well as other predefined user and groups,
are used in various server programs.
Most server programs must be run initially as
(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
The original process usually dies.
Common examples of
services that work this way include Apache (
So you often have a need for a plain ol' user account and group for
On Unix platforms it is common to use either user "
a special user account created expressly for that purpose (with
login disabled for that account), and group "
On Linux group
nobody is usually used instead
(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
must update a file (such as "
from a CGI program,
then the file must be read/write for the user (or less often group)
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 "
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
There are many pre-defined groups listed.
These are for various specific services (e.g., "
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
However, some pre-defined groups are meant to have additional users
For example group
wheel on BSD and Linux systems, and
sysadmin on Solaris.
On Debian-based Linux systems, many access controls are determined by
For example only members of the "
plugdev" group can
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
/sbin/nologin for the account's shell).
When adding a new service, configure that
service to use new user and group ids, not "
or other pre-defined groups.
Finally remember that groups should reflect a set of users with
common access needs.
rw" means that a file is readable and writable but not executable. Back
umask" value controls the default permissions applied to newly created files and directories. Back
NFSthan the limit is 16 groups per user. This limit is historical and could be removed in future versions of Unix. (It has been removed from Linux as of version