Special Permissions: SUID (Set User ID)

Borrowing Superpowers Temporarily

Normally, when you run a program, it executes with your user's permissions. If you can't read a file, the program can't read it for you.

However, some programs need elevated privileges to do their job. Consider the passwd command, which lets you change your password. It needs to write to the sensitive /etc/shadow file, which is owned by root and not writable by regular users.

How can you run passwd and have it modify a root-owned file?

The answer is the SUID (Set User ID) bit. When set on an executable file, it tells Linux: "When this program runs, execute it with the permissions of the file's OWNER, not the user who launched it."

Since passwd is owned by root and has the SUID bit set, it runs with root privileges, even when you (a regular user) run it.

SUID is set symbolically (chmod u+s) or as a leading 4 in four-digit octal (chmod 4755), and appears as an s in the owner's execute position of the permission string — /usr/bin/passwd itself typically shows -rwsr-xr-x, owned by root. If the owner's execute bit were missing, it would show as S (uppercase) instead, meaning the bit is set but has no effect.

How SUID works internally:

When you execute a SUID binary, the kernel sets the process's effective user ID (EUID) to the file owner's UID, while keeping the real user ID (RUID) as your UID. Well-written SUID programs check both and drop privileges as soon as they no longer need them—this is called "privilege dropping" and is a critical security practice.

Security implications:

SUID is a major security risk. If a program with SUID has a bug (buffer overflow, command injection, etc.), an attacker could exploit it to gain root privileges. This is why:

1. Only a handful of system utilities should have SUID. On a typical Linux system, fewer than 20 binaries have SUID set — utilities like passwd, sudo, su, mount, and ping, each of which genuinely needs a brief privilege boost to do its one job: writing to /etc/shadow, spawning processes as another user, modifying the kernel's mount table, or opening a raw network socket.
2. Never set SUID on scripts. Most Linux kernels ignore SUID on interpreted scripts for security reasons.
3. Audit SUID binaries regularly. Search the filesystem for files with the SUID bit set to catch anything unexpected.

Key Point: In production, SUID binaries are a prime target for privilege escalation attacks. During security audits, always check for unexpected SUID files, especially in web application directories or user home directories. A common attack vector is uploading a SUID binary to a web server and exploiting it to gain root access. Use the nosuid mount option for filesystems where users can write files (e.g., /home, /tmp) to prevent SUID execution on those filesystems entirely.