SUID lets a program temporarily borrow the privileges of whoever owns its file, rather than running with the privileges of whoever launched it. It solves a real problem, and it is also one of the most common paths attackers look for once they have any foothold on a compromised system.

What SUID actually changes

ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 Mar  1 09:00 /usr/bin/passwd
#     └── an 's' here instead of the usual 'x'

Under normal circumstances, a program runs with the permissions of whoever executes it. If you run passwd, it should only be able to do whatever your own regular user account is allowed to do. But changing your password requires writing to /etc/shadow, a file only root can modify. The SUID bit resolves this contradiction: when a SUID-marked executable runs, it temporarily executes with the privileges of the file’s owner (root, in this case), not the privileges of the user who launched it.

whoami
# colton

passwd
# runs WITH root privileges internally, even though colton
# launched it, specifically so it can write to /etc/shadow

# the moment passwd finishes, colton's shell is still just
# a normal, unprivileged colton shell, completely unaffected

Why this specific mechanism exists

A handful of everyday actions genuinely require a brief, narrow moment of elevated privilege: changing your own password, locking your terminal session, or certain low-level networking operations that historically required raw privileges. Rather than granting every regular user broad root access just to perform these specific, narrow tasks, the responsible program itself is marked SUID and owned by root. The program gains root privileges only for the duration of its own execution, and (assuming it is well-written) only uses that privilege for its specific, intended purpose, like writing exactly one line to /etc/shadow.

ls -l /usr/bin/passwd /usr/bin/su /usr/bin/sudo
# -rwsr-xr-x 1 root root  ... /usr/bin/passwd
# -rwsr-xr-x 1 root root  ... /usr/bin/su
# -rwsr-xr-x 1 root root  ... /usr/bin/sudo

passwd, su, and sudo itself are all classic SUID-root binaries, since all three need a controlled path to acting with root privileges on behalf of a regular user.

Why SUID is treated as a real security concern

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

Any binary marked SUID and owned by root is, by design, a program that grants root-level privilege the moment it executes. If that program has a bug, an unintended code path, or can be tricked into running an unexpected command (for example, if it shells out to another program without fully controlling that program’s own input), an attacker who can execute it may be able to escalate from a limited, unprivileged foothold to full root access.

This is why security audits routinely run exactly the find command above, searching the entire filesystem for every SUID binary, and compare the result against a known-good baseline. An unexpected SUID binary showing up that was not there before, especially a custom script someone marked SUID for convenience, is a serious red flag during a security review.

# A dangerous, illustrative example of what NOT to do:
sudo chmod u+s /usr/bin/some_custom_script.sh
# marking a shell script SUID is especially risky, since shell
# scripts are particularly easy to manipulate into running
# unintended commands with the elevated privilege they now carry

Marking a shell script SUID specifically is widely considered especially dangerous, and modern Linux kernels often ignore the SUID bit on scripts entirely as a built-in mitigation, applying it reliably only to compiled binary executables.

Setting and removing SUID

chmod u+s program
ls -l program
# -rwsr-xr-x ... program

chmod u-s program
ls -l program
# -rwxr-xr-x ... program (back to a normal, non-privileged executable)

In numeric mode, SUID is the leading fourth digit, valued at 4:

chmod 4755 program
# equivalent to chmod 755 followed by chmod u+s

Reading s vs S in ls -l output

ls -l /usr/bin/passwd
# -rwsr-xr-x   (lowercase s: SUID set, AND owner execute is also present)

ls -l some_weird_file
# -rwSr--r--   (uppercase S: SUID set, but owner execute is NOT present,
#               meaning SUID has no real effect since the file cannot
#               be executed at all)

An uppercase S generally signals a misconfiguration: the SUID bit is set on a file that is not actually executable, meaning the bit has no functional effect at all, since SUID only matters when the file is actually run as a program.

Frequently Asked Questions

What does the SUID bit do?

SUID (Set User ID) is a special permission bit that, when set on an executable file, causes the program to run with the privileges of the file’s owner rather than the privileges of the user who actually launched it. If a program owned by root has the SUID bit set, it runs with root privileges no matter which regular user executes it.

Why does Linux need SUID at all?

Some ordinary user actions genuinely require a brief moment of elevated privilege to complete safely. Changing your own password, for instance, requires writing to /etc/shadow, a file that only root can normally modify. Rather than making every user a full sudoer just to change their own password, the passwd program is given the SUID bit, owned by root, so any user running it briefly gains exactly the privilege needed to update that one file, and nothing more.

What is a classic example of a program that uses SUID?

/usr/bin/passwd is the textbook example. Check it with ls -l /usr/bin/passwd, and you will see an s in the owner’s execute position instead of the usual x. This lets any regular user run passwd and have it write to the root-owned /etc/shadow file to update their own password hash, without that user needing broad root access for anything else.

Why is SUID considered a security risk?

Any SUID program owned by root is effectively a doorway to root privileges if it contains a bug or can be tricked into behaving unexpectedly, such as being made to execute an unintended command or read an unintended file. Attackers specifically search compromised systems for SUID binaries as a path to privilege escalation. A poorly chosen or unnecessary SUID bit on a custom script is one of the more common ways a system gets compromised further after an initial, more limited breach.

How do I find all SUID binaries on a system?

Run find / -perm -4000 -type f 2>/dev/null, which searches the entire filesystem for files with the SUID bit set, discarding permission-denied errors from directories you cannot search. Comparing this list against a known-good baseline, or against what a fresh installation of the same distribution normally has, is a standard part of routine security auditing.

How do I set or remove the SUID bit on a file?

Use chmod u+s filename to add the SUID bit, or chmod u-s filename to remove it. In numeric mode, SUID is represented by a leading fourth digit of 4, so chmod 4755 sets standard rwxr-xr-x permissions plus the SUID bit in a single command.