SUID, SGID, Sticky & umask

Special Permission Bits

Beyond the basic rwx model, Linux has three special bits that solve real, recurring problems. They're rare enough to be genuinely confusing the first time you meet them, so let's ground each one in the problem it exists to solve.

The problem SUID solves: when you run passwd to change your own password, it needs to write to /etc/shadow - a file only root can normally touch. But you're not root. SUID (Set User ID) makes a program run with the file owner's identity instead of the identity of whoever launched it - so passwd (owned by root, with SUID set) briefly runs as root just long enough to update the shadow file safely, then exits.

The problem SGID solves (on directories): normally, a new file inherits the creating user's primary group. On a shared team directory, that means files created by different teammates end up in different groups, breaking shared access. SGID on a directory forces every new file created inside it to inherit the directory's group instead, so a whole team's files stay in one consistent group automatically.

The problem sticky bit solves: /tmp is writable by everyone (so any user can create temp files there) - but that would normally also mean anyone can delete or rename anyone else's files in that directory, since directory write permission covers both. The sticky bit carves out an exception: even with directory write access, you can only delete or rename files you own.

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 59976 /usr/bin/passwd   # s = SUID
$ ls -ld /tmp
drwxrwxrwt 10 root root 4096 /tmp              # t = sticky

Notice the lowercase s replaces the owner's execute bit in the listing, and the t replaces the "other" execute bit on /tmp - that's how ls -l visually signals these special bits are set, layered on top of the normal permissions.

Set them with a fourth leading octal digit: chmod 4755 file (SUID), chmod 2775 dir (SGID), chmod +t dir (sticky).

umask

Every time a program creates a new file, it doesn't get maximum permissions by default (666 for files, 777 for directories) - the shell subtracts a mask called umask first, so newly created files start out reasonably locked down without every program having to think about it.

umask 022  →  files 644, dirs 755   (typical default)
umask 077  →  files 600, dirs 700   (private)

Warning: The basic rwx model only distinguishes three audiences: owner, group, other. Real teams often need finer control - "bob specifically can write this file, but the rest of the group can only read it." That's what ACLs (Access Control Lists) are for: setfacl -m u:bob:rw file grants bob a permission independent of the normal owner/group/other rules, and getfacl file shows the full list. Once ACLs are in play, ls -l shows a + right after the permission string - if you ever see that + and the visible rwx bits don't seem to explain someone's actual access, check getfacl before you assume chmod is broken.