Understanding Group Permissions in UNIX
To get a basic understanding of how permissions work in UNIX, I suggest
reading the web pages at
Or you can read the short tutorial on our
Security web page.
Once you have an understanding of the basics, then you can read the
following about setting files areas for group sharing.
Most people first worry about permissions when they want to share file
write access with a group of people. The key to nearly seemless group file
access requires two factors:
Because having umask set to 002 means all files you create will be by
default group writable, it is important that ones default group be their
own personal group (only that user is a member).
Then in "non-group" areas where the SETGID permission is not set,
all new files a user creates will be in the user's default group. They
will be group writable, but it is a group of just one -- the user.
The most common directory where this matters is the user's home directory.
All new user accounts at the Martinos Center are created such that in
the default ~/.cshrc file there is the line 'umask 0002'.
Also each new accounts default group is the user's personal group.
GOTCHAS: programs that move, copy, extract, etc files (e.g. mv, cp, tar, rsync)
preserve the permissions of the files from the source area and ignore
the group/setgid setting of the destination. This is where most people
get in trouble and then send email to me asking why such and such files
are not group writable. There is no magic fix for this. Users just need
to be aware of this issue and fix it (see below). In the case of rsync
though there are some helpful options as outlined in the
Group Permissions section of our rsync tutorial.
CSH SCRIPTS: it is important that all C-shell (csh/tcsh) scripts
you create include the -f option. In otherwords, the first line
of your scripts should be:
The setgrp Script
There is a script I created named setgrp you can run on a directory
to make that directory and all files and subdirectories under it "shared"
by particular group. It will only be able to do this to files the user
running the script owns. So everyone with files in a group area would need
to run it to guarantee permissions are "fixed" for group access. When
this is a big problem, you can sent a request to the help desk to run
setgrp as root so it gets all users.
The following example sets the director /space/sake/5/admin to be
a "group area" for the sysadm group
/usr/pubsw/bin/setgrp -c sysadm /space/sake/5/admin
- All directories and files are put in group sysadm
- All directories are set with the 'rws' in the group position
- All files are set to be 'rw' in the group position
- Any world writable permission on any files/dirs are unset
- Only files/dirs owned by the user running setgrp are changed
- Only files needing changes are changed
You can give setgrp the "-h" option to get a list of options.