chmod 2775: The setgid Bit on Directories and on Files

The problem setgid solves on a directory is the one every shared folder hits. A file created inside a 775 directory takes the creator's primary group, not the directory's, so Alice creates a file owned by alice:alice and the rest of the team can read it but not edit it. Nobody notices until someone tries to change it days later.

With the setgid bit on the directory, new entries inherit the directory's group automatically, and new subdirectories inherit the setgid bit as well, so the property propagates down the tree without anyone remembering to reapply it. Combined with a umask of 002, which leaves the group write bit set, a team gets a directory where collaboration simply works.

It does not fix files that already exist. Setting 2775 changes the behaviour from that moment on, so an existing tree needs a one time pass with chgrp to correct the group, and usually a chmod to restore group write. Doing the setgid change and forgetting the historical fix is the most common half completed version of this.

On an executable file, setgid means something different: the process runs with the file's group rather than the caller's. That is how a small number of utilities get access to a device or a spool directory without being setuid root. The write utility being setgid to the tty group is the example most people have on their machine.

The security profile is much milder than setuid. A setgid binary gains one group's access rather than a whole identity, and setgid on a directory grants nothing at all, it only changes which group new files belong to. It is still worth knowing where it is set, because a setgid directory quietly changes ownership rules for everything created inside it.