I have seen advice in several places to use the following shebang line#!/usr/bin/env bashinstead of#!/usr/bin/bashMy knee-jerk reaction is, what if somebody substitutes this executable for their own in say ~/.local/bin ? That directory is often set up in the user's path before the system-wide paths. I see this raised as a security issue often as a side note rather than anything to take seriously, but I wanted to test the theory.To try this out I did something like this:echo -e #!/usr/bin/python\nprint 'Hacked!' > $HOME/.local/bin/bashchmod 755 $HOME/.local/bin/bashPATH=$HOME/.local/bin env bashThis yields/usr/bin/env: bash: No such file or directoryTo check whether it was picking up anything at all I also didecho -e #!/usr/bin/python\nprint 'Hacked!' > $HOME/.local/bin/perlchmod 755 $HOME/.local/bin/perlPATH=$HOME/.local/bin env perlwhich prints, as I expected,Hacked!Can someone explain to me why the substitute bash is not found, but the substitute perl is? Is this some sort of security measure that (from my point of view) misses the point?EDIT: Because I have been prompted: I am not asking how /usr/bin/env bash is different from using /bin/bash. I am asking the question as stated above.EDIT2: It must have been something I was doing wrong. Tried again today (using explicit path to env instead of implicit), and no such not found behaviour.
/usr/bin/env as a shebang - and its security implication
bash;security;environment variables
what if somebody substitutes this executable for their own in say ~/.local/bin ?Then the script doesn't work for them.But that doesn't matter, since they could conceivably break the script for themselves in other ways, or run another program directly without messing with PATH or env.Unless your users have other users' directories in their PATH, or can edit the PATH of other users, there's really no possibility of one user messing another one.However, if it wasn't a shell script, but something that grants additional privilege, such as a setuid wrapper for some program, then things would be different. In that case, it would be necessary to use an absolute path to run the program, place it in a directory the unprivileged users cannot modify, and clean up the environment when starting the program.