22.5 Group Permissions in a Directory with the setgid Bit

If you work on a UNIX system with lots of users, you may be taking advantage of UNIX group permissions (22.2 ) to let users in one group write to files in a directory - but not let people in other groups write there.

How does UNIX determine what group should own the files you create? There are three ways:

1. On most System V-based systems, the effective group ID of the process determines the ownership of the files you create. (Your effective GID is your primary group membership (22.13 ) unless you're running a SGID (1.23 ) program.)

2. On most BSD UNIXes, files are owned by the group that owns the directory in which you create the file .

3. The rules under SunOS 4.x and System V Release 4 are more complicated. The system administrator decides which of the two above methods a filesystem will use for group ownership. There are other wrinkles, too. A good place to look for the gory details is your system's open (2) manpage... but it's probably easier to just create an empty new file (21.7 ) and then check the group ownership with ls -l or -lg (22.2 ) .

   You may be able to use the directory's set group ID (setgid) bit to control group ownership. In those cases, if the bit is set, the BSD rules apply. if the bit is not set, the System V rules apply. To set and remove the setgid bit, use the commands chmod g+s (22.7 ) and chmod g-s , respectively.

You can use the chgrp (1.23 ) command to change a file's group. However, you must own the file. And you must also be a member of the file's new group.

If you've reset directory mode bits, it's possible to wind up with ls -l permissions that have an uppercase "S", like drwxr-S-- . What's that? (It's often a mistake.) The directory's setgid bit is set, but the execute bit isn't set. If you want the directory to be group-accessible, add execute permission with chmod g+x . Otherwise, you may want to clear the setgid bit with chmod g-s .