Setuid on Shell Scripts Silently Fails on Linux — Use sudo -A or pkexec Instead

No — on Linux the setuid bit is silently ignored when the file is an interpreted script, so a root-owned, rwsr-xr-x script still runs with your ordinary user account. That is why ls /boot/efi inside it fails with "Permission denied": neither the script nor the ls process it spawns ever becomes root. The underlying goal — a graphical script that performs privileged steps without a terminal prompt — is still achievable, but setuid is the wrong tool for it.

Why setuid does nothing on scripts

The kernel honors setuid only when it executes a real compiled binary. A file starting with #! is not executed directly: the kernel launches the interpreter named on the shebang line and hands the script to it as an argument. The interpreter binary is not setuid, so the entire process tree runs unprivileged and the bit on the script is decorative.

This is deliberate. Early Unix systems did support setuid interpreters, but the design enabled classic race attacks (swap the script between the kernel's check and the interpreter's read), so support was removed everywhere modern. The same rule applies to file capabilities set with setcap: honored on binaries, ignored on scripts.

Bash adds a second barrier. If it starts with an effective UID different from its real UID, it assumes something suspicious is happening and drops itself back to the real, unprivileged UID. So even making /bin/bash itself setuid accomplishes nothing — which is just as well, given what a setuid shell would mean for system security.

Confirm the behavior with id

You can watch the difference in a minute. Copy a real binary, mark the copy setuid, and run it:

cp /bin/id /tmp/id-suid
sudo chown root:root /tmp/id-suid
sudo chmod 4755 /tmp/id-suid
/tmp/id-suid

The output shows two different UIDs: your real one and an effective UID of 0. That is setuid working as designed on a binary. Run the same test against a shell script and both values are your own UID — proof that elevation never happened. Your diagnosis was close but slightly off: ls would have inherited root's effective UID from its parent. The parent simply never had it to pass on.

Split the GUI from the privilege

Zenity itself never needs root — it only draws windows. What needs root are the specific commands the script runs, so elevate those individually:

• sudo -A with a graphical askpass. Point SUDO_ASKPASS at a tiny helper that runs zenity --password, then call privileged commands as sudo -A apt install …. You keep sudo's timestamp-based caching, so repeat calls within the timeout do not re-prompt.
• pkexec. Part of PolicyKit, which desktop environments ship anyway. pkexec apt install whatever pops the desktop's native authentication dialog and supports per-action policies. It replaces plain sudo calls one for one.
• run0 or systemd-run on recent systemd releases routes through PolicyKit the same way.
• A scoped sudoers rule. If the flow must run with no prompt at all, allow exactly one dedicated helper script with NOPASSWD — never a blanket NOPASSWD: ALL.

gksudo shows up in older guides but is effectively unmaintained; prefer pkexec or sudo -A.

The trap: elevating the whole script

A tempting shortcut is to have the script re-launch itself through pkexec when it notices it is unprivileged. That backfires with Zenity: once the whole script runs as root, it is no longer the desktop session's owner, cannot connect to the display, and every dialog silently fails. The workarounds — sharing X authority, whitelisting root on the X server — punch holes in session security and behave unpredictably on Wayland.

There is a subtler issue too. Sudo caches passwords by time; PolicyKit caches authorization per process. A shell script is really a swarm of short-lived processes, so each separate pkexec call starts with no memory of the last one and prompts again. Long-lived GUI applications can request authorization once and hold it; a shell script cannot. The practical fix is consolidation: gather everything privileged into a single helper invocation instead of sprinkling pkexec throughout the script.

Design so there is nothing to exploit

Whatever route you take, keep the privileged surface minimal. Leave the GUI script unprivileged, move the actual work into one narrow root-side helper that validates its own input, and permit only that helper through sudoers or a PolicyKit policy. A setuid script, even if it worked, would hand root to anything that could modify or trick that file — which is exactly why the mechanism was abandoned decades ago.

Frequently Asked Questions

Does setuid work on Python or Perl scripts either?

No. The kernel ignores setuid on any file executed through an interpreter, regardless of language, and most interpreters additionally drop privileges if launched elevated.

Why did the script run at all if setuid was ignored?

It ran as your normal user the whole time. The only failure was ls being unable to read a root-only directory, which is the expected outcome for an unprivileged process.

Can I just setuid the bash binary?

Bash detects that its effective and real UIDs differ and resets itself to the real UID at startup, so it will not stay elevated. Even if it did, a setuid shell would be a system-wide root hole.

How do I stop pkexec from asking for a password on every call?

You cannot cache it across processes the way sudo caches by time. Bundle all privileged work into one pkexec or helper call, or switch those calls to sudo -A and rely on sudo's timestamp cache.

Why do my Zenity dialogs vanish when the script runs as root?

Root is not the owner of the graphical session, so it lacks the credentials to talk to the X or Wayland server. Keep the script itself unprivileged and elevate only individual commands.

Is there any safe way to make a setuid script?

Not on modern Linux. Use a sudoers rule scoped to a dedicated helper script or a PolicyKit policy; both give you passwordless or graphically authenticated elevation without the attack surface of setuid scripts.