If you master octal 755 you already know half of Unix permissions. The other half —special bits and umask— explains behaviors that look magical: why passwd can modify root-only /etc/shadow, why you can't delete others' files in /tmp despite write permission, and why your new files are born with certain modes. It all has logic and takes ten minutes to learn.
Quick base-model recap
Every file carries three rwx triplets (read/write/execute) for owner, group and others. Octal sums bits: r=4, w=2, x=1.
-rwxr-x--- 1 miguel dev 4096 aug 27 file.sh
└┬┘└┬┘└┬┘
│ │ └─ others: --- (0)
│ └──── group: r-x (5) → 754
└─────── owner: rwx (7)
Semantics differ by type: on files, x = executable; on directories, r = list names, x = traverse (access contents), w = create/delete entries. That nuance causes the classic confusion: a r-- directory shows names but can't be entered; --x allows access knowing the exact path but not listing.
Special bits: the fourth digit
Octal accepts four digits: the first encodes special bits (setuid=4, setgid=2, sticky=1).
Setuid (4000) on an executable: runs with the FILE OWNER's privileges, not the launcher's. Canonical case is /usr/bin/passwd:
-rwsr-xr-x root root /usr/bin/passwd
↑ lowercase s = setuid active
Changing your password requires writing /etc/shadow, which only root touches. Thanks to setuid, the passwd binary temporarily elevates, updates shadow, drops back. It's intentional privilege escalation — and that's why any unexpected setuid-root binary is an instant audit finding (find / -perm -4000 -user root).
Setgid (2000) has two lives:
- On executables: like setuid but for group.
- On directories: every file created inside inherits the DIRECTORY's group instead of creator's primary group. The key piece of team directories:
mkdir /srv/project
chgrp devs /srv/project
chmod 2775 /srv/project # 2=setgid + rwxrwxr-x
Without setgid, Ana creates files owned by group ana and Bob can't edit them despite sharing devs. With it, everything is born collaborative. Combined with proper default permissions it solves 90% of server sharing pain.
Sticky bit (1000) on directories: only the file's owner (or directory owner, or root) may DELETE it, even in a world-writable directory. Its only real case is /tmp:
drwxrwxrwt 22 root root /tmp
↑ t = sticky
Without sticky bit, anyone could delete others' temp files in a 777 directory — trivial denial of service. With it, universal write, own-only delete.
Umask: birth permissions
When you create a file, why does it come out 644 not 666? Enter umask: the mask SUBTRACTING permissions at creation.
Processes request maximums (files 666, dirs 777 — x isn't granted by default on new files for safety) and umask filters:
final = request AND NOT umask
umask 022: 666 & ~022 = 644 (rw-r--r--)
777 & ~022 = 755 (rwxr-xr-x)
umask 077: 666 & ~077 = 600 (rw-------) ← paranoid, ideal for keys
777 & ~077 = 700
Check yours with umask (octal) or umask -S (symbolic). Set per session/profile (~/.bashrc) or globally via /etc/profile and PAM. Real use cases: corporate multi-user servers do well with 027 (group reads, others nothing); services generating private keys must run umask 077 — an SSH key born 644 triggers OpenSSH's known warning.
ACLs: when three triplets aren't enough
The classic model has a hard limit: one group per file. Needing "devs read+write, auditors read-only, web service read" brings POSIX ACLs:
setfacl -m g:auditors:r-x /srv/project
getfacl /srv/project
They appear as trailing + in ls -l (drwxrwxr-x+). Enough for most file servers; large systems move to NFSv4/Samba models.
Permission hygiene: what audits check
- Unexpected setuid binaries (especially /home or writable paths).
- Shared directories without setgid (team pain) or without sticky (delete risk).
- World-readable config files with credentials (
find /etc -perm -004). - SSH/SSL private keys above 600 — OpenSSH outright refuses them.
To calculate and visualize octal/symbolic combinations without mental math, our chmod calculator translates formats instantly; the system's foundation lives in the octal permissions guide.
FAQ
Why do I see uppercase T instead of t? Sticky bit set but no execute permission for others (drwxrw-rw-T). Same with S on setuid: special bit without x — almost always wrong state, sign of a misapplied chmod.
Do cp and mv preserve permissions? mv within same filesystem yes (only renames the entry); cp creates fresh applying umask unless -p. Critical detail when copying keys or configs across machines.
Does chmod 777 fix "permission denied"? Almost never correct and opens real holes. Diagnose WHICH user runs the process, WHICH permission exactly is missing (traversing a dir?), grant minimal.
Calculate octal and symbolic permissions with our chmod calculator, free and right in your browser.