Runner: Change `#!/bin/bash` shebangs to `#!/usr/bin/env bash` for better compatibility

[evanrelf]

Some operating systems don't have a Bash executable located at /bin/bash (e.g. NixOS does this intentionally), so shell scripts using #!/bin/bash as their shebang won't function without modification.

I suggest replacing #!/bin/bash with #!/usr/bin/env bash to improve compatibility with systems that don't have /bin/bash.

I'm willing to implement this change — it's a pretty simple change — but I'm presenting the idea first as an issue.

[NorseGaud]

I had some kid tell me this was a huge security vulnerability at my last job, but he never gave me a good reason why. I wonder if anyone else has an opinion...

[evanrelf]

@NorseGaud /usr/bin/env bash means "use the bash in my PATH."

In theory, if someone had access to your machine, they could change your PATH variable to include a malicious script named bash.

In practice, if someone had that level of access, you would have much bigger problems. Plus, making your script use /bin/bash instead of /usr/bin/env bash wouldn't help, since the person could change your shell config in other ways (e.g. run malicious code in your shell prompt), or modify the script to use their own malicious shebang.

[Mic92]

Nixpkgs/NixOS maintainer here. It is not just NixOS and Guix. FreeBSD has bash in /usr/local/bin. MacOS bash at /bin/bash is ancient and people might want to replace it with homebrew's bash. Also see this discussion in systemd: https://github.com/systemd/systemd/pull/5816
TL;DR upstream should rely on the developers/user's PATH for flexibility. Linux distribution have control over their binaries during packaging and have infrastructure replace /usr/bin/env shebangs automatically with absolute paths to the right binaries.

[Mic92]

I had some kid tell me this was a huge security vulnerability at my last job, but he never gave me a good reason why. I wonder if anyone else has an opinion...

That might be the case if you have binaries in setuid scripts (very bad idea in the first place). But than you also need to do a lot of hardening in general i.e. use absolute PATHs everyhere or set your own PATH and sanitize other environment variables. I don't think this applies here.