The issue is that there's an unavoidable race condition which renders SUID for interpreted (ie. #!) executables insecure. Suppose there's some SUID bash script

The issue is that there's an unavoidable race condition which renders SUID for interpreted (ie. #!) executables insecure. Suppose there's some SUID bash script owned by root in the system that starts with "#!/bin/bash". I (an unprivileged user) create a symlink "./foo" to "/path/to/SUID_script". I execute "./foo". The kernel follows foo, reads the SUID script's #!, and so runs "/bin/bash ./foo". Honoring the SUID, bash is run as root. Here's the race. In between the kernel doing this and bash finishing initialisation and reading its script arg, I swap out the "foo" symlink to instead point at "./my_evil_code". So bash reads "./foo" and executes the content as root. I now have arbitrary code execution as root. Are there ways this could be fixed? Possibly. But not easily. It's not enough to just say "SUID can't work through a symlink" - I could've symlinked to the SUID script's parent directory, for example. You can't say "the kernel should pass the fully resolved path to the interpreter", this will break a million scripts that rely on changing behaviour based on $0. I share your pain about wanting an easy, non-compiled means of creating a small SUID program. But I don't see any good way unless something changes. Maybe a util that takes a #! interpreted file, adds an ELF header and some machine code that execs the desired interpreter and feeds it static script content?