나는 다음 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암시적 경로 대신 명시적 경로 사용 ) 그러한 "찾을 수 없는" 동작은 없습니다.
답변1
"누군가 ~/.local/bin 에서 이 실행 파일을 자신의 실행 파일로 대체하면 어떻게 될까요?
그러면 스크립트가 작동하지 않습니다.
그러나 그것은 중요하지 않습니다. 왜냐하면 그들은 다른 방법으로 스스로 스크립트를 깨뜨릴 수 있거나 또는 를 건드리지 않고 직접 다른 프로그램을 실행할 수 있기 때문 PATH입니다 env.
사용자가다른사용자의 디렉터리를 자신의 에 저장 PATH하거나 PATH다른 사용자의 디렉터리를 편집할 수 있으므로 한 사용자가 다른 사용자를 망칠 가능성은 실제로 없습니다.
그러나 쉘 스크립트가 아니고 일부 프로그램에 대한 setuid 래퍼와 같이 추가 권한을 부여하는 스크립트라면 상황이 달라집니다. 그렇다면,필요한절대 경로를 사용하여 프로그램을 실행하려면 권한이 없는 사용자가 수정할 수 없는 디렉터리에 경로를 저장하고 프로그램을 시작할 때 환경을 정리하세요.
답변2
셸과 셸 사이의 동작 차이에 관해서는 perl셸 perl과 달리 셸은 첫 번째 줄을 검사하여 실행할 항목을 결정합니다.
$ cat tcl
#!/usr/bin/env tclsh
puts "TCL running as [pid]"
$ perl tcl
TCL running as 39689
$ cat sbcl
#!/opt/local/bin/sbcl --script
(format t "~a running as ~a~%" 'lisp (sb-unix:unix-getpid))
$ perl sbcl
LISP running as 39766
$
이 기능의 용도는 다음과 같습니다.Perl 이외의 다른 언어로 테스트 작성따라서 다른 언어로 된 TAP 호환 스크립트를 가질 수 있으며 prove또는 기타 등등이 이를 올바르게 실행할 수 있습니다.
답변3
여기에는 보안 위험이 없습니다. /usr/bin/env사용자의 환경에 따라 적절한 바이너리를 선택하도록 되어 있습니다. 따라서 사용자가 bash에 자신의 것을 설치했다면 ~/.local/bin실제로 /usr/bin/env그것을 사용해 보아야 합니다(예를 들어 시스템 전체 버전에서 사용할 수 없는 추가 기능이 포함된 버전을 컴파일했을 수 있으며 에서 사용하는 것을 선호할 수 있습니다). 시스템 전체 버전의 위치). 다른 바이너리/인터프리터에서도 마찬가지입니다. 사용자는 어쨌든 실행할 수 없었던 어떤 것도 실행할 수 없기 때문에 보안 위험이 없습니다.
귀하의 경우 대체품이 실패하는 이유에 대해서는 그것이 /usr/bin/env. 를 실행해 보고 PATH=~/.local/bin bash( PATH=~/.local/bin bash <path-to-script>스크립트를 실행할 때 호출됨) PATH=~/.local/bin /usr/bin/env bash그중 어느 것이 실패하는지 확인하세요. 이는 "파일을 찾을 수 없음" 오류가 무엇을 의미하는지에 대한 단서를 제공합니다.