If you’ve already got chmod, chown, and basic rwx down, this is where permissions get genuinely interesting — and where most junior engineers make mistakes that silently break production systems.
Round 1 gave you the foundation. Round 2 is about the permission layer underneath the basics: the special bits that change how executables and directories behave, and umask, which controls what permissions files get the moment they’re born.
The Three Special Bits
Linux has three extra permission bits beyond the standard rwx set: SUID, SGID, and the Sticky Bit. Each one sits in the same permission string you already know — they just occupy the execute slot in a special way.
SUID — Set User ID
When SUID is set on an executable file, the process runs with the permissions of the file’s owner, not the user who launched it.
The classic example is passwd:
ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Mar 2 2024 /usr/bin/passwd
See that s in the owner-execute slot? That’s SUID. Any user can run passwd and it briefly runs as root — just long enough to write to /etc/shadow, which no ordinary user can touch directly. The program itself enforces what it allows.
Setting SUID:
chmod u+s /path/to/binary
# or in octal, prepend 4:
chmod 4755 /path/to/binary
What SUID does NOT do on directories: It has no meaningful effect. If you see SUID on a directory, it’s almost certainly a misconfiguration.
Security implication: A SUID root binary with a code vulnerability becomes a root privilege escalation path. This is why attackers routinely scan for SUID binaries during post-exploitation.
# Find all SUID binaries on the system — useful for auditing
find / -perm -4000 -type f 2>/dev/null
SGID — Set Group ID
SGID behaves differently depending on whether it’s set on a file or a directory.
On an executable file: The process runs with the permissions of the file’s group, not the user’s primary group. Less common than SUID, but the same principle.
On a directory: This is the useful one. When SGID is set on a directory, new files and subdirectories created inside it inherit the directory’s group, not the creating user’s primary group.
mkdir /srv/team-project
chown :developers /srv/team-project
chmod g+s /srv/team-project
ls -ld /srv/team-project
drwxrwsr-x 2 root developers 4096 Apr 8 10:00 /srv/team-project
Now when any member of developers creates a file inside /srv/team-project, the file belongs to group developers — not their own personal group. This is how shared directories are meant to work in a team environment. Without SGID, files would be owned by whatever each user’s primary group is, creating a fragmented mess.
Setting SGID:
chmod g+s /srv/team-project
# or octal, prepend 2:
chmod 2775 /srv/team-project
Sticky Bit
The sticky bit today is almost exclusively used on directories. When set, it means: only the file’s owner (or root) can delete or rename a file in this directory, even if other users have write permission on the directory itself.
/tmp is the canonical example:
ls -ld /tmp
drwxrwxrwt 22 root root 4096 Apr 8 09:45 /tmp
The t in the others-execute slot is the sticky bit. Everyone can write to /tmp. But you cannot delete someone else’s file there — only the file’s owner or root can.
Setting the sticky bit:
chmod +t /srv/shared-uploads
# or octal, prepend 1:
chmod 1777 /srv/shared-uploads
Use cases beyond /tmp: Any shared upload directory, any folder where multiple users write but shouldn’t be able to sabotage each other’s files.
Reading the Full Permission String
Once you combine special bits with standard permissions, the permission string can look confusing. Here’s how to read it:
-rwsr-xr-x → SUID set, runs as file owner
-rwxr-sr-x → SGID set, runs as file group
drwxrwsr-x → SGID on directory, new files inherit group
drwxrwxrwt → Sticky bit on directory
What if the execute bit is not set in the relevant slot, but the special bit is?
-rwSr--r-- → SUID set, but no execute permission (capital S = broken)
drwxrwSr-x → SGID set on directory, but group has no execute (capital S)
drwxrwxrwT → Sticky bit set, but others have no execute (capital T)
Capital S and T indicate the special bit is set but execute is missing. On an executable, this is almost always a mistake. On a directory, S for SGID is sometimes valid depending on intent, but T without execute is unusual.
The Octal Map for Special Bits
If you prefer working in octal (and you should for scripting):
| Bit | Octal value |
|---|---|
| SUID | 4 |
| SGID | 2 |
| Sticky | 1 |
These go in a fourth leading digit before the standard rwx triple:
chmod 4755 file # SUID + rwxr-xr-x
chmod 2775 dir # SGID + rwxrwxr-x
chmod 1777 dir # Sticky + rwxrwxrwx
chmod 6755 file # SUID + SGID + rwxr-xr-x (rare, but valid)
umask — Where Default Permissions Come From
Every file and directory has permissions the moment it’s created. Those permissions don’t come from nowhere — they come from umask.
How it works
The kernel starts with maximum permissions and subtracts whatever umask specifies:
- Files: kernel starts with
0666(no execute by default — execute is never set on a new file automatically) - Directories: kernel starts with
0777
umask then masks out (removes) bits.
umask
0022
With umask 0022:
Files: 0666 - 0022 = 0644 → -rw-r--r--
Directories: 0777 - 0022 = 0755 → drwxr-xr-x
This is why files you create are usually 644 and directories are 755 — that’s the 0022 umask doing its job.
Changing umask
# Check current umask
umask
# Set a more restrictive umask (no group or other access)
umask 0077
# Files: 0600 -rw-------
# Directories: 0700 drwx------
# Set a collaborative umask (group gets write)
umask 0002
# Files: 0664 -rw-rw-r--
# Directories: 0775 drwxrwxr-x
umask 0002 is common in team environments where group collaboration is expected.
Where umask is set
umask is a per-process setting — it’s inherited from the shell. For system-wide defaults:
/etc/profile— applied for login shells/etc/bash.bashrcor/etc/bashrc— applied for interactive shells/etc/pam.d/common-session— PAM-based sessions (used bypam_umask)
To check what your current session’s umask applies to, just run umask and create a test file:
umask 0022
touch testfile && ls -l testfile
# -rw-r--r-- 1 limon limon 0 Apr 8 10:30 testfile
umask is not chmod in reverse
A common confusion: umask does not work like chmod. umask removes bits — it cannot add them. If you set umask 0000, files still won’t get execute permission, because the kernel never grants +x to new regular files in the first place.
Quick Reference: Special Bits + umask
| Concept | What it does | Where it applies |
|---|---|---|
| SUID (4) | Run as file owner | Executable files |
| SGID (2) | Run as file group / inherit group | Executables + directories |
| Sticky (1) | Only owner can delete | Directories |
| umask | Filters default permissions on new files | All new files/directories |
What to Verify When AI Sets These
When you prompt an AI to configure permissions with special bits, verify:
- SUID/SGID is on an executable — not a random config file
- SGID on a directory shows a lowercase
sinls -ld, not uppercaseS(which means execute is missing) - The umask value makes sense for the context —
0022for single-user,0002for shared group environments find / -perm -4000after changes to confirm SUID is only where expected
Part 2 covers Access Control Lists (ACLs) — the mechanism for fine-grained permission control beyond the owner/group/others model, and real-world troubleshooting when permissions silently break things.
Leave a Reply