You run `chmod 4755` on a root-owned shell script, and it still executes with the caller's own privileges rather than root's. Why does Linux ignore the set-user-ID bit here, when it honours it on a compiled binary?

## What exec really does with a `#!` file The `#!` line is a kernel feature, not a shell one. When `execve()` is given a file whose first two bytes are `#!`, the kernel reads the interpreter path from that line, and then **executes the interpreter**, passing it (optionally one literal argument from the `#!` line, then) the original file's path. Your `argv[0]` handling and the script name arrive as ordinary arguments. So two files are involved: the script whose bit you set, and the interpreter that actually becomes the process image. The credential change on exec is decided by the file the kernel loads as the process image. Since that file is the interpreter — an ordinary, non-privileged executable — no privilege transition occurs. ``` $ printf '#!/bin/sh\nid -u\n' > /tmp/whoami.sh $ sudo chown root /tmp/whoami.sh $ sudo chmod 4755 /tmp/whoami.sh $ ls -l /tmp/whoami.sh # -rwsr-xr-x, the bit is clearly there $ /tmp/whoami.sh # still prints your own UID ``` The bit is visible, which is exactly why this trips people up. Nothing warns you; the script just quietly does not gain privilege. ## Why the rule exists This is a deliberate refusal, not an oversight. Running interpreters with borrowed privilege is genuinely hard to do safely: - **The interpreter obeys the caller's environment.** A shell reads variables that change how it resolves commands and files; other interpreters read variables that add module search paths or preload code. A privileged interpreter under the caller's environment is a privileged program the caller partly configures. - **There is a race between the kernel's read and the interpreter's open.** The kernel opens the script to read the `#!` line, then execs the interpreter, which opens the script *by path* a second time. On a directory the caller can write, the path can be pointed at different content in between — a privileged interpreter would then execute the substitute. Some Unixes added a special file-descriptor mechanism to close this; Linux chose not to honour the bits at all. - **The interpreter is generic.** A compiled setuid program can drop privilege for most of its work; a general-purpose interpreter has no idea which lines of the script need root and will happily run whatever the file contains. So Linux ignores set-user-ID and set-group-ID on scripts. Some other Unix systems permit it, sometimes behind a mount or kernel option — one more reason not to assume a shell script's privilege behaviour ports between platforms. ## What people do instead **A small compiled wrapper.** A short C program that is itself set-user-ID root, hard-codes the absolute path of the script or command it may run, sanitises the environment rather than inheriting it, and validates its arguments before doing anything. The privilege lives in a tiny, reviewable file. Written carelessly — inheriting the environment, taking the target path from an argument, launching a command by bare name — the wrapper is simply a slower way to hand out root. **Ask a privileged service instead.** The unprivileged script sends a request over a socket or a queue to a long-running privileged component that performs a narrow, well-defined operation and validates it against the requester. This inverts the trust: the privileged code decides what is allowed instead of trusting whoever invoked it. **Grant the narrow power rather than the identity.** Where the task needs one specific ability rather than root wholesale, granting exactly that is far better than an identity swap — the general principle being that set-user-ID is all-or-nothing and almost always over-grants. ## Two related gotchas worth knowing - **`chmod 4755` on a script is not harmless just because it does nothing.** It leaves a file that *looks* privileged, which will confuse the next reviewer and will trip a security scanner. Clear it with `chmod u-s`. - **The bit is equally inert if the execute bit is missing.** `ls` then shows `S` instead of `s` — a set-user-ID file that cannot be executed at all. - **A compiled binary that merely *calls* a shell reintroduces every problem.** Setting the bit on a compiled program that shells out to run your script gets you the interpreted-privilege problem back, with the wrapper providing only the illusion of a boundary. The crisp answer in an interview: the kernel applies the bits to the image it loads, the image it loads for a `#!` file is the interpreter, and Linux refuses the transition because a privileged interpreter under the caller's control is not defensible.