umask, SUID/SGID/sticky bit and ACLs

Understand how umask sets default permissions, how special bits can be abused for privilege escalation, and how ACLs grant fine-grained rights to one user without widening a group.

umask: default permissions

New files start at 666 (directories 777) minus the umask. With umask 022, files are 644 and directories 755. Sensitive servers often use 027 (others cannot read) or 077 for accounts holding private data. Check it with umask; set it permanently in /etc/login.defs or the shell profile, while systemd services use UMask= in the unit.

flowchart LR
  U["alice runs passwd<br/>-rwsr-xr-x"] --> S{"SUID bit<br/>set?"}
  S -- "yes" --> R["Runs as owner<br/>root"]
  S -- "no" --> A["Runs as alice"]
  R --> RISK["Bug = root shell<br/>privilege escalation"]
  F["find / -perm -4000<br/>inventory"] --> RISK
  ACL["setfacl u:alice:rw<br/>one extra user"] --> A
  %% step U: A user runs a program; ls -l shows s in the owner's execute slot for SUID.
  %% step S: The kernel checks the special bits before starting the process.
  %% step R: With SUID the process runs with the file owner's rights, often root.
  %% step A: Without it the process has only the caller's rights.
  %% step RISK: A buggy SUID-root binary is a classic privilege-escalation path.
  %% step F: Inventory SUID files regularly and remove the bit where it is not needed.
  %% step ACL: To give one person access, use an ACL instead of widening permissions with chmod 777.

The three special bits

Bit	Octal	On a file	On a directory
SUID	`4000`	Runs with the owner's rights (for example `passwd`)	Not used
SGID	`2000`	Runs with the group's rights	New files inherit the directory's group
Sticky	`1000`	Not used	Only owners may delete their files (`/tmp`)

In ls -l, SUID shows as s in the owner's execute slot: -rwsr-xr-x. A buggy SUID-root binary is a common privilege-escalation path, so inventory them regularly:

sudo find / -xdev -perm -4000 -type f 2>/dev/null

-perm -4000 means "has at least the SUID bit"; writing -perm 4000 (no minus) matches only files whose mode is exactly 4000, which is almost nothing. Remove unneeded SUID with sudo chmod u-s /path/to/bin, and mount data partitions such as /tmp with the nosuid option.

ACLs: fine-grained rights

Owner/group/others is sometimes too coarse: you want only alice to read and write a file without adding her to the group. ACLs do that:

setfacl -m u:alice:rw report.txt      # give alice rights
setfacl -m d:g:devops:rx shared/      # default ACL for new files in a directory
getfacl report.txt                    # show ACLs
setfacl -x u:alice report.txt         # remove alice's entry

A file with ACLs shows a + after the mode (-rw-rw-r--+). The mask entry caps the rights of every named user and group entry, so a later chmod g-w can silently weaken the ACL.

Traps

Using chmod 777 to "fix" a permission error instead of granting the right person.
Forgetting that Linux ignores SUID on shell scripts; SUID only affects binaries.
Not checking ACLs when permissions look right but access is still denied, or still allowed.