sh는 $PATH를 고려하지 않습니다.

Question 1

POSIX에서는 sh구현이 현재 작업 디렉터리에서 찾을 수 없을 때 검색할 수 있도록 허용 file하지만(사양의 기반이 되는 하위 집합) 그렇게 하기 때문에 이를 요구하지 않으며 요즘 대부분의 구현에서는 이를 요구하지 않습니다(또는 심지어). 이는 바람직하지 않습니다.$PATHsh filefilekshshshmksh

실제로 POSIX에서는 이를 허용하며 일부 구현에서는 반대 문제가 발생합니다.

sh -- "$file"

POSIX는 경로가 저장된 파일의 해석을 보장하지 않으므로 $file다음을 수행해야 합니다.

case $file in
  ('') echo >&2 error;;
  (*/*) sh -- "$file";;
  (*) sh "./$file";;
esac

휴대용으로 해결해보세요.

이것이 사람들이 다음을 사용하는 것을 보는 이유이기도 합니다.

sh ./file

file현재 디렉터리에서 해석되고 있는지 확인하고 현재 작업 디렉터리가 아닌 현재 작업 디렉터리에서 명령을 실행하는 것과 같이 누락된 경우 완전히 관련되지 않은 일부 스크립트를 해석하는 위험을 감수 $PATH하지 않으려는 경우 .file./lsls$PATH

이 유틸리티에는 포함되지 않은 .비슷한 $PATH문제 가 있습니다 . POSIX는 sh 모드가 아닐 때 bash 또는 zsh에서 파일을 찾는 것을 허용하지 않지만 현재 디렉터리의 파일을 해석하는 폴백을 허용하지 않습니다. '에 해당 : 검색 하지 않습니다 . 에서 찾기 로 돌아갑니다 . 에서는 동작이 와 유사 합니다 .$file/$PATHcsh.source$PATHzshsource$PATHbashsource.

여기에서 스크립트가 에 있고 $PATH실행 권한이 있다고 가정하면 다음과 같이 간단히 입력할 수 있습니다.

gap.sh

gap.sh에서 찾으 려면 $PATH. 스크립트에 shebang이 없으면 shPOSIX 호환 인터프리터로 해석해야 합니다.

읽기 권한이 있지만 실행 권한이 없는 경우 다음을 수행할 수 있습니다.

sh -c '. gap.sh' sh arguments for gap.sh

$PATH위에 표시된 대로 조회가 수행됩니다 .

역사적으로 on 이 ksh file먼저 검색 ksh되었습니다 $PATH. 이는 setuid 스크립트를 지원하는 시스템의 보안 취약점입니다. 다음과 같이 할 수 있습니다.

ln -s /path/to/some/setuid/ksh/script /tmp/file
echo sh > ~/bin/file
PATH=$PATH:~/bin
cd /tmp

exec("file", ...)shebang으로 which를 호출하면 setuid 사용자로 실행 #! /bin/ksh -되고 대신 해석되므로 스크립트가 setuid 루트인 경우 루트 쉘을 얻게 됩니다./bin/ksh - fileksh~/bin/file/tmp/file

Answer