special permissions overview

Overview

Beyond basic rwx, Linux has special permission bits — setuid, setgid, and the sticky bit — that change how files execute or how directories behave. They are powerful and, in the case of setuid, a frequent focus of privilege-escalation analysis. This lesson introduces them.

Learning objectives

• Describe setuid, setgid, and the sticky bit.
• Explain the security impact of setuid programs.
• Recognize these bits in a permission listing.

Core concept

Three special bits augment the standard permissions:

• setuid (SUID) — on an executable, it runs with the privileges of the file's owner rather than the user who launched it. If owned by root, it runs as root.
• setgid (SGID) — on an executable, it runs with the file's group privileges; on a directory, new files created inside inherit that directory's group.
• Sticky bit — on a shared directory, it restricts deletion so users can only remove their own files (famously used on /tmp).

In ls -l, these appear as s (setuid/setgid) or t (sticky) in place of an x.

How it works

A setuid root program temporarily elevates any user who runs it to root for that program's duration — this is intentional for a few trusted tools (e.g. passwd, which must update root-owned files), but dangerous if a flawed or unnecessary program has it. setgid on a directory ensures collaborative files share a common group. The sticky bit makes world-writable shared directories safe by preventing users from deleting each other's files. You set these with chmod (e.g. chmod u+s, chmod g+s, chmod +t).

Practical example

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 59976 ... /usr/bin/passwd
$ ls -ld /tmp
drwxrwxrwt 10 root root 4096 ... /tmp

The s in passwd's owner triplet marks it setuid root, so any user running it briefly acts as root to change their password. The trailing t on /tmp is the sticky bit, letting everyone create files there but only delete their own.

Cybersecurity relevance

setuid root binaries are a top privilege-escalation target: if such a program has a vulnerability, exploiting it can yield root. During assessment, enumerating setuid files (e.g. via find / -perm -4000) is standard, and any unexpected or custom setuid-root binary is a red flag. Defenders minimize setuid programs to only trusted, necessary ones. The sticky bit, conversely, is a protective measure for shared directories.

Common mistakes

• Adding setuid to programs that do not need it, creating escalation risk.
• Confusing setgid on files vs directories — on directories it controls group inheritance.
• Forgetting the sticky bit on world-writable shared directories, letting users delete each other's files.

Key takeaways

• Special bits: setuid (run as file's owner), setgid (run as file's group; on directories, inherit group), sticky (only owners can delete their files in a shared directory).
• They appear as s or t in ls -l and are set with chmod.
• setuid-root binaries are a major privilege-escalation focus (enumerate and minimize them); the sticky bit protects shared directories like /tmp.

Check your understanding

• What does the setuid bit do when set on a root-owned executable, and why is that a privilege-escalation concern?
• What problem does the sticky bit solve on a world-writable directory like /tmp?