On a Linux host, `ls -ld /tmp` prints `drwxrwxrwt`. What does that trailing `t` do, and why is it needed on a world-writable directory?

## Why the bit exists at all The surprising premise behind this question is that **deleting a file has nothing to do with the file's permissions**. Removing a name from the filesystem is `unlink()`, and `unlink()` modifies the *directory* that holds the name, not the file's data. So the kernel checks write and search permission on the **containing directory**. A read-only file owned by root can be deleted by anybody who can write the directory it lives in; a file you own and have full `rwx` on cannot be deleted if the directory is not writable by you. That rule is fine for `/home/alice`, where only Alice can write. It falls apart for a shared scratch directory. `/tmp` must be writable by every user on the machine so that any process can drop temporary files there — but a plain mode `0777` directory would let any user delete or rename any other user's temporary files, which is trivially a denial-of-service and, worse, the setup for a swap-the-file race. ## What the sticky bit actually restricts The sticky bit (`S_ISVTX`, octal `1000`) is the fix. When it is set on a directory, an entry inside it may only be renamed or unlinked by: - the owner of the file, - the owner of the directory, or - a privileged process (one holding `CAP_FOWNER`). Everything else is unchanged: any user with write permission can still **create** new entries, and read permissions on existing files are untouched. The bit narrows exactly one operation — removing or renaming somebody else's name. ``` $ ls -ld /tmp drwxrwxrwt 18 root root 4096 ... ``` ## Reading and setting it `ls -l` has no spare column, so the three special bits are overloaded onto the execute positions. The sticky bit appears in the **other-execute** slot: lowercase `t` means the bit is set *and* other-execute is also set; uppercase `T` means the sticky bit is set but the directory is not searchable by others — which is usually a mistake on a shared directory, since nobody could enter it. Set it numerically as a fourth leading octal digit, or symbolically: ``` chmod 1777 /srv/scratch chmod +t /srv/scratch chmod -t /srv/scratch ``` ## What it does not do This is where candidates lose points. - **It does not protect file contents.** If a file inside the sticky directory is itself world-writable, another user can still open it and overwrite or truncate it in place. The name survives; the data does not. The sticky bit protects the *directory entry*, not the inode. - **It does not stop reading.** Anything world-readable in `/tmp` is readable by everyone on the box. - **It does not close symlink and hardlink races.** A classic attack is planting a symlink in `/tmp` that a privileged program later follows or truncates. Linux hardens this separately with the sysctls `fs.protected_symlinks` and `fs.protected_hardlinks` (plus `fs.protected_fifos` and `fs.protected_regular`), which restrict following symlinks and creating hardlinks in world-writable sticky directories when the owners do not match. They are enabled by default on current distributions and are a separate mechanism from the mode bit. - **On Linux it is meaningless on a regular file.** The name is a fossil: on early Unix the bit asked the kernel to keep a program's text segment in swap so it reloaded faster. Linux ignores it on regular files entirely; the modern meaning is the directory rule only. ## Where you meet it in practice Beyond `/tmp` and `/var/tmp`, the same pattern appears on `/dev/shm`, on shared upload or spool directories, and anywhere multiple service accounts write into one place. If you build such a directory yourself, mode `1777` — or better, `1770` with a shared group so the world cannot even list it — is the standard shape. The interviewer's real target is whether you know that deletion is a directory-level right. Say that first, then the bit follows naturally: the sticky bit is the one exception the kernel makes to "write on the directory means you can remove anything in it".