Please note that this announcement dates to 2004.
This message applies to everyone that uses groups on the Linux operating system, including those accessed via Samba shares. If you never touch Linux or the Linux file system, or never share files with anyone else on Linux, you may skip the rest of this message.
As part of our plan to retire Tru64 UNIX and replace it with Linux, we are in the process of moving all files from a UNIX file server (HAL) to a Linux file server (GRIFFON). Thus far we have moved all the /project directories. The /home and /aux directories will be moved in the coming weeks.
We have found one difference between the two operating systems that will be important to anyone that shares files within a group. In Tru64 UNIX, when you create a new file, it is by default given the same group affiliation as the directory that contains it. In Linux (and every other UNIX implementation we're aware of), when you create a new file, its group affiliation is by default set to your primary group. This is intended to increase security: a file will not be shared with a group unless you explicitly make it belong to that group. Whether this precaution is more trouble than it's worth could be debated, but that is how Linux works and we cannot change it.
Take an example from our handbook: user kvelyvis belongs to four groups: sxnet, hospital, prcensus, and palloni. The palloni group is her primary group, since user palloni is her advisor. Under Tru64 UNIX, if she created a file in a directory belonging to the hospital group, the file would be affiliated with the hospital group. If she gave group read or group write permissions, other members of the hospital group could read or modify the file. But under Linux, the new file would belong to the palloni group, not the hospital group, as palloni is her primary group. Members of the hospital group will not be able to read or modify the file even if she gives group read and group write permissions (unless they happen to also be members of the palloni group).
There is one other complication that will make this change even more important: in many applications, if you save an existing file, the program actually deletes the old file and then writes a new one with the same name. Thus the group affiliation will be reset to your primary group every time the file is saved (note that in Tru64 UNIX it would be reset to the directory's group affiliation, so this isn't really new).
As a result you may need to become more familiar with the chgrp (change group) command. It's very simple to use:
> chgrp group filename
where group is the name of the group you want the file to be affiliated with, and filename is the name of the file. You can use the * wildcard to change everything in the current directory, or add the -R option to act on all subdirectories of the current directory. If you want both, type:
> chgrp -R group *
Use with caution!
You do have the option of making a particular directory act like it used to in Tru64 UNIX, i.e. new files will be given the group affiliation of the directory. Simply type:
> chmod g+s directory
where directory is the name of the directory you want to change. If you're feeling brave, this daunting command will do the same for the current directory and all its subdirectories (or contact the consultant and we'll be happy to do it for you):
> find . -type d -print0 | xargs -0 chmod g+s
Note however, that any new directories you create will default back to the standard behavior--new files will belong to the user's primary group, not the directory's group--unless you use one of the above commands change it as well.
SSCC staff will be very happy to help you with this change. This includes changing the group ownership of any files or directories that got reset, and changing the behavior of any or all of your existing directories. But you'll still need to be aware of the issue when you create new directories. Please contact the consultant if you have any questions (email@example.com, 2-9917, or stop by 4315 Social Science).
Go to previous editions of SSCC News. Go to the SSCC Home Page.
© 2004 University of Wisconsin Social Science Computing Cooperative