chmod 4755: The setuid Bit and What It Actually Does

Setuid solves a real problem. Changing your own password means writing to a file only root may write, so /usr/bin/passwd is owned by root with the setuid bit set, and when you run it the process gets root's effective user id for the duration. The same trick is what lets ping open a raw socket and what historically let mount work for ordinary users.

It is also the classic privilege escalation surface. A setuid root binary with a buffer overflow, a shell injection, or a careless use of an environment variable hands root to anyone who can run it. That is why the number of setuid binaries on a modern system keeps shrinking, and why capabilities, which grant one specific privilege rather than the whole identity, are preferred for new code.

Two things silently disable it. Linux ignores setuid on interpreted scripts entirely, because the gap between the kernel checking the file and the interpreter opening it was exploitable, so a setuid shell script simply runs as you. And any file system mounted with nosuid ignores the bit, which is standard for removable media and for many container and temporary mounts.

The rendering tells you whether it is doing anything. Lowercase s in the owner position means setuid with the execute bit also set, which is the working combination. Capital S means the setuid bit is set while the owner execute bit is not, which is almost always an accident and achieves nothing, because there is nothing to execute.

Auditing for it is straightforward and worth doing periodically. A find across the file system for the setuid bit lists every binary that can run as someone else, and anything on that list that you did not expect deserves an explanation. The calculator flags setuid with a security warning for the same reason.