Linux File Permissions Explained: chmod, chown, and umask

Originally published on DevToolHub.

chmod 755, chmod 2775, umask 022 — the numbers make sense once you see where each digit comes from. This is the actual bit math, plus the chmod-and-symlinks gotcha that causes real incidents.

The numeric mode math

Each digit sums read(4), write(2), execute(1). chmod 644 = owner read+write (6), group read-only (4), other read-only (4). A fourth leading digit controls the special bits: setuid(4), setgid(2), sticky(1) — chmod 2775 sets setgid on top of 775.

Setgid on directories

New files created inside a setgid directory inherit the directory's group automatically — no manual chgrp needed. Linux clears the setgid bit on a regular file if its group doesn't match your effective or supplementary groups, a real security guard against silent privilege leakage. Directories preserve setuid/setgid by default; clearing them needs a leading zero, minus, or equals in the numeric mode.

The sticky bit is two different features

On a directory, it's the exact mechanism that makes /tmp safe to be world-writable — only a file's owner can delete it, even though everyone can write to the directory. On a regular file, it's an obsolete swap-caching hint modern kernels ignore entirely.

chmod never touches the symlink itself

chmod changes what a symlink points to, not the link's own mode — the system call can't change a symlink's permissions on most systems, so chmod follows it instead. chmod 700 mylink can quietly modify a shared target file. Use -h/--no-dereference if you actually mean the link.

umask only affects what's created next

chown alice:devs file sets owner and group in one call; chown alice: alone resets the group to alice's login group. umask sets the creation mask for the current shell only — it does nothing to existing files, and a mask set inside a subshell or nohup command doesn't carry back to the parent shell.

Full breakdown: devtoolhub.com/linux-file-permissions-explained