/usr/bin/env 作为shebang - 及其安全含义

Question

我在几个地方看到了使用以下shebang行的建议

#!/usr/bin/env bash

代替

#!/usr/bin/bash

我的下意识反应是，“如果有人用这个可执行文件代替他们自己的 ~/.local/bin怎么办？” 该目录通常设置在系统范围路径之前的用户路径中。我认为这是作为一个安全问题提出的，通常是作为旁注而不是任何值得认真对待的事情，但我想测试这个理论。

为了尝试这个，我做了这样的事情：

echo -e "#!/usr/bin/python\nprint 'Hacked!'" > $HOME/.local/bin/bash
chmod 755 $HOME/.local/bin/bash
PATH=$HOME/.local/bin env bash

这产生

/usr/bin/env: ‘bash’: No such file or directory

为了检查它是否捡到任何东西，我也做了

echo -e "#!/usr/bin/python\nprint 'Hacked!'" > $HOME/.local/bin/perl
chmod 755 $HOME/.local/bin/perl
PATH=$HOME/.local/bin env perl

打印出来，正如我所料，

Hacked!

有人可以向我解释为什么bash找不到替代品，但找到了替代品perl吗？这是某种“安全”措施（从我的角度来看）没有抓住要点吗？

编辑：因为我被提示：我不是问/usr/bin/env bash与使用/bin/bash. 我在问上面提到的问题。

EDIT2：一定是我做错了什么。今天再次尝试（使用显式路径env而不是隐式路径），没有这种“未找到”行为。

Answer 1

“如果有人在说 ~/.local/bin 中用这个可执行文件代替他们自己的怎么办？

然后脚本对他们不起作用。

但这并不重要，因为他们可以想象以其他方式为自己破坏脚本，或者直接运行另一个程序而不会弄乱PATH或env。

除非你的用户在他们的 目录中有其他用户的目录PATH，或者可以编辑其他用户的目录，否则PATH一个用户真的不可能搞乱另一个用户。

但是，如果它不是 shell 脚本，而是授予额外特权的东西，例如某些程序的 setuid 包装器，那么情况就会有所不同。在这种情况下，需要使用绝对路径来运行程序，将其放置在非特权用户无法修改的目录中，并在启动程序时清理环境。