If you set the setuid bit on a shell script owned by root, does it run as root?

A common beginner assumption is that chmod u+s script.sh on a root-owned script gives a quick root-run helper. On Linux it does not, which also shapes how you audit for privilege escalation.

What the kernel does

The execve(2) manual page states that Linux "(like most other modern UNIX systems) ignores the set-user-ID and set-group-ID bits on scripts." The kernel launches the interpreter named in the #! line, and the effective UID stays that of the caller. Part of the reason is historical race conditions between the kernel checking the script file and the interpreter reopening it.

Where the bit does apply

The set-user-ID bit is honoured when executing a native binary. The same man page lists cases where it is skipped, including when the filesystem is mounted nosuid. Behaviour on nosuid mounts varies by kernel version: some refuse the execution with EPERM, others run the file without the privilege change.

Security takeaways

When auditing a Linux host, enumerating SUID binaries is productive; SUID scripts are not. If admins need a privileged helper, the usual alternatives are a small compiled wrapper, a carefully restricted sudo rule, or file capabilities, each of which has its own risks.

Why the distractors are tempting

"Runs as root" is the intuitive answer. "Only if world-writable" and "only bash" invent validation rules that do not exist.

What interviewers want

"Linux ignores SUID on scripts; it works for compiled binaries; nosuid mounts disable it too," and the audit implication.