Bash
/usr/bin/env 作為 shebang - 及其安全含義
我在幾個地方看到了使用以下 shebang 線的建議
#!/usr/bin/env bash
代替
#!/usr/bin/bash
我的下意識反應是,“如果有人用這個執行檔代替他們自己的 say
~/.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
而不是隱式路徑),並且沒有這樣的“未找到”行為。
“如果有人在 ~/.local/bin 中用這個執行檔替換他們自己的文件怎麼辦?
然後腳本對他們不起作用。
但這並不重要,因為可以想像他們可以通過其他方式為自己破壞腳本,或者直接執行另一個程序而不會弄亂
PATH
orenv
。除非您的使用者在他們的目錄中有其他使用者的目錄
PATH
,或者可以編輯其他使用者的目錄,否則PATH
一個使用者真的不可能弄亂另一個使用者。但是,如果它不是 shell 腳本,而是授予額外特權的東西,例如某些程序的 setuid 包裝器,那麼情況就會不同。在這種情況下,必須使用絕對路徑來執行程序,將其放置在非特權使用者無法修改的目錄中,並在啟動程序時清理環境。