12.3 SGID on Directories: Inherited Group Ownership
Right, so you’ve got SUID figured out for files. It’s weird, but it makes a sort of twisted sense. Now let’s talk about its cousin for directories, SGID. This is where things get genuinely useful instead of just dangerously interesting.
When you set the SGID bit on a directory (chmod g+s), you’re changing the rules of the game for any new file or directory created within it. Here’s the rule: any new item created inside an SGID directory will have its group ownership set to the group owner of the parent directory, not the primary group of the user who created it.
Why on earth would you want this? Think of it as enforced teamwork. Imagine a directory /shared/docs owned by root:developers. Without SGID, when I (user mike, whose primary group is mike) create a file in there, it’s owned by mike:mike. The developers group can’t necessarily edit it. That’s a problem. We want all the developers to be able to collaborate seamlessly.
SGID fixes this mess. Set the SGID bit, and now when I create new_plan.txt in /shared/docs, its ownership becomes mike:developers. The group ownership is inherited from the parent directory. Now any member of the developers group can probably read and write to it (depending on the directory’s permissions, but you get the idea). It’s the magic that makes shared group directories actually work.
Setting It and Seeing It
Let’s build this from the ground up. First, we’ll create a directory and a group, then set it up properly.
# As root, create a shared group and directory
sudo groupadd developers
sudo mkdir /shared_docs
sudo chown root:developers /shared_docs
sudo chmod 2775 /shared_docs # That '2' is the SGID bit in numeric mode
# Let's see the permission set. Look for the 's' in the group execute field.
ls -ld /shared_docs
# drwxrwsr-x 2 root developers 4096 Jun 10 10:00 /shared_docs
# See that `rws`? The 's' means SGID is set AND the directory is executable.
# Now, let's add a user (you) to the 'developers' group and test.
sudo usermod -aG developers $USER
# You need to log out and back in for the group membership to take effect, or use 'newgrp'
Now for the test. After logging back in:
# Check your groups
groups
# youruser developers ...other groups...
# Navigate and create a file
cd /shared_docs
touch our_shared_file.txt
ls -l our_shared_file.txt
# -rw-r--r-- 1 youruser developers 0 Jun 10 10:05 our_shared_file.txt
Boom. The file is owned by you, but its group is developers, inherited from the parent directory /shared_docs. This wouldn’t happen without that SGID bit.
The Subtleties and the Gotchas
This isn’t magic, it’s a system call, and that means there are edge cases.
First, the mkdir command is well-behaved. When you create a new subdirectory inside an SGID directory, the new directory will also have the SGID bit set. This is brilliant—it means the inheritance rule propagates down the entire directory tree, making it perfect for complex shared projects.
mkdir /shared_docs/a_new_subdir
ls -ld /shared_docs/a_new_subdir
# drwxr-sr-x 2 youruser developers 4096 Jun 10 10:07 a_new_subdir
See the r-s? The SGID bit is already set on the new subdirectory.
Now, the most common pitfall: this only works if the application creating the file respects the rules. Most do. But some programs, like cp or text editors when doing a “save as,” can be told to explicitly preserve the original group ownership (cp -p) or set a specific one. This can override the SGID behavior. The rule is this: if the program calls chown() or chgrp() explicitly after creating the file, it can change the group. The SGID behavior happens at the moment of creation during the open() or mkdir() syscall. So always test your workflow.
Best Practices and When to Use It
Use SGID on directories liberally for any shared workspace. It’s the correct, secure way to handle group collaboration. Relying on world-writable directories (chmod 777) is the act of a barbarian and a sure path to privilege escalation and chaos.
The numeric permission for SGID is the digit 2 prepended to the usual three. So 2755, 2770, 2775 are all common. My go-to is 2770 (rwxrws—) for directories where only the group needs access, and 2775 (rwxrwsr-x) if others need read and traverse access.
Remember, the SGID bit on a directory is almost always a good idea. It’s the SUID bit on random files that will get you into trouble. This tool is for coordination, not elevation, and it does that job beautifully.