setgid, short for set group ID and often written SGID, is a special Linux permissions bit with two distinct effects. On an executable file, it makes the program run with the group identity of the file instead of the group of the user who started it. On a directory, it makes new files and subdirectories inherit the directory’s group, which is the standard way to build shared team folders.
The bit belongs to the three special permission bits alongside setuid and the sticky bit. It occupies the value 2000 in octal notation, is set with chmod and appears in ls -l output as an s in the group execute position, for example drwxrwsr-x.
How the set group ID bit works on executables
Every Linux process has a real group ID inherited from the user and an effective group ID used for permission checks. When the kernel executes a file with the setgid bit, it sets the process’s effective group ID to the group owner of the file. The process can then access resources that this group may access, even if the calling user is not a member.
The design follows the principle of least privilege more closely than setuid root. Instead of granting full superuser rights, a program receives the rights of one dedicated group, such as a group that may write to terminals or read a shared database. A compromise of such a program exposes only what that group can reach.
The kernel applies several safeguards. The bit is ignored for interpreted scripts on Linux, it has no effect on file systems mounted with the nosuid option, and it is cleared automatically when the file is modified by an unprivileged user or when its owner changes, so a tampered binary does not keep elevated group rights.
Group inheritance on directories
On a directory, setgid changes how group ownership of new entries is assigned. Normally a new file receives the creating user’s primary group. Inside a setgid directory, it receives the directory’s group, and new subdirectories also receive the setgid bit, so the behavior propagates down the tree.
This solves a common collaboration problem. Without the bit, files created by different team members end up with different groups, and colleagues lose access. With setgid on the shared directory, a suitable umask such as 002 and group write permission, every file remains editable by the whole group.
| Target | Effect of the bit | Typical use |
|---|---|---|
| Executable file | Process runs with the file’s group as effective group | Utilities that need one privileged group |
| Directory | New entries inherit the directory’s group | Shared project and team folders |
| Subdirectory created inside | Inherits the setgid bit itself | Consistent behavior in the whole tree |
| Non-executable regular file | No privilege effect on modern Linux | Historically marked mandatory locking |
Setting and reading the bit
The bit can be set symbolically or numerically with chmod. The symbolic form chmod g+s dir adds it without touching other bits, while the octal form places the special digit before the usual three, so chmod 2775 dir means setgid plus rwxrwxr-x. Changing the group itself is done with chgrp or chown.
| Command | Result | Notes |
|---|---|---|
| `chmod g+s shared` | Adds setgid to a directory | Other permission bits stay unchanged |
| `chmod 2770 shared` | Setgid with full access for owner and group only | Others receive no access |
| `chmod g-s file` | Removes the bit | Use after auditing unnecessary privileges |
| `chgrp devteam shared` | Sets the group that will be inherited | Set before or after the bit |
| `find / -perm -2000 -type f` | Lists setgid executables | Standard step in a security audit |
In ls -l output, a lowercase s in the group execute position means both setgid and group execute are set. An uppercase S means setgid is set but group execute is not, which on a regular file usually indicates a misconfiguration rather than a working privilege.
Comparison with setuid and the sticky bit
The three special bits are often learned together but solve different problems. The table contrasts them.
| Bit | Octal value | On executables | On directories |
|---|---|---|---|
| setuid | 4000 | Runs with the file owner’s user ID | Ignored on Linux |
| setgid | 2000 | Runs with the file’s group ID | New entries inherit the group |
| Sticky bit | 1000 | No effect on modern Linux | Only owners may delete their files |
Shared directories frequently combine setgid with the sticky bit, giving the mode 3775 or 3770. Setgid keeps group ownership consistent, while the sticky bit prevents team members from deleting each other’s files. For finer control, such as giving a second group read-only access, Linux ACLs with default ACL entries complement or replace the setgid approach.
Security considerations and pitfalls
Setgid executables are part of the system’s attack surface. A flaw in such a program, for example unsafe handling of environment variables or file paths, can let a user act with the privileged group’s rights. Security audits therefore list all setgid files and compare them with an expected baseline.
- Keep setgid binaries to a minimum and remove the bit where it is no longer needed.
- Never rely on setgid shell scripts, because the kernel ignores the bit for them.
- Mount removable media and user-writable partitions with nosuid to neutralize planted binaries.
- Remember that existing files do not change when setgid is added to a directory; fix them with chgrp -R.
- Set a group-friendly umask for shared directories, or inherited groups will lack write access.
The simple explanation
Think of setgid as a team badge rule. On a shared folder, it means that every new document placed there automatically belongs to the team, not to the person who created it. Everyone on the team can keep working with it.
On a program, the rule lets the program borrow the team’s badge while it runs. It can open doors that only that team may open, but nothing more.
How it is used in practice
A web development agency keeps its project files on a Linux server in /srv/projects. Four developers belong to the group webdev, but files they created ended up with their personal primary groups, so colleagues regularly hit permission denied errors when editing each other’s work.
The administrator ran chgrp -R webdev /srv/projects, set `chmod 2775` on every directory in the tree and configured a umask of 002 for the developers. From then on, every new file and folder belonged to webdev with group write access, and subdirectories carried the setgid bit automatically. The permission errors stopped without giving anyone root access, and onboarding a new developer only required adding the account to the group.