Setuid

Setuid (set-user-ID) is a permission bit on Unix-like systems that causes an executable to run with the effective UID of the file's owner rather than the user who launched it. Encoded as 4000 in octal, it appears in `ls -l` as an `s` (or `S` if execute is unset) in the owner's execute slot. The mechanism dates to Dennis Ritchie's 1979 patent on AT&T's behalf and was placed into the public domain; it remains the canonical way to grant ordinary users tightly scoped access to privileged operations. The textbook example is `/usr/bin/passwd`. The file is owned by root and has setuid set, so when any user runs it the resulting process can edit `/etc/shadow` — a file readable and writable only by root. Other historical setuid-root binaries include `ping` (needs raw sockets), `mount`, `su`, and `sudo`. On Linux, raw sockets and many mount cases have migrated to capabilities (`CAP_NET_RAW`, `CAP_SYS_ADMIN`), reducing the surface that needs full setuid root. Setuid is a double-edged tool. Because the kernel hands the process a different UID, any defect — buffer overflow, environment-variable trust, unsafe `system()` call, race in a setuid shell script — can become a privilege escalation primitive. The Unix tradition is to write setuid programs defensively: drop privileges with `setresuid` as early as possible, sanitise the environment, and avoid invoking external commands. Modern hardening adds the `nosuid` mount option (which makes the kernel ignore setuid bits on a filesystem), AppArmor/SELinux confinement, and periodic audits with `find / -perm -4000`. Setuid does not apply to shell scripts on most modern kernels: Linux silently drops the bit for interpreted files because the race between kernel exec and the interpreter opening the script is unfixable in general. Setuid on a directory is a no-op on Linux; on some other Unixes it affects new-file ownership.