누군가 현재 작업 디렉토리에 Foo.sh라는 쉘 스크립트를 가지고 있다고 가정해 보겠습니다. 그것은 다음과 같이 읽힌다
#!/bin/bash
#some scripts below
"./Foo.sh"를 입력하여 스크립트를 실행하려면 실행 권한이 필요합니다. 대신에 그는 단순히 "bash Foo.sh"를 실행하고 해당 스크립트를 프로그램 bash에 인수로 전달하여 스크립트를 실행하도록 선택할 수 있습니다. 후자의 경우에는 읽기 권한만 필요합니다.
이것은 나에게 권한 반전처럼 보입니다. 즉, 사용자는 실행 권한이 없는 실행 파일을 실행할 수 있습니다.
내 질문은 다음과 같습니다
이것은 어느 정도 합법성을 지닌 의도적인 디자인입니까, 아니면 호환성 이유로만 유지되는 레거시 문제입니까?
이에 대한 보안 위험이 있습니까?
답변1
이것은 편리한 장치입니다. shebang 라인은 인터프리터를 스크립트에 하드코딩합니다. 편리할 뿐만 아니라 파일 확장자와 마찬가지로 정보도 제공합니다. 다른 인터프리터로 계속 실행할 수 있습니다.
bash script.undefined
또는
sh script.undefined
아니면 어쩌면
perl script.undefined
등.
보안 관점에서도 마찬가지다. 두 경우 모두 활성 사용자의 유효 사용자 ID가 파일을 읽고 실행하는 데 사용됩니다.끈끈한 비트해석된 언어에는 영향이 없지만 이는 또 다른 이야기입니다. (사실 이는 보안에 있어서 중요합니다.)
답변2
기술적으로는 예상대로 작동합니다. 당신이 달릴 때
./foo.sh
foo.sh 프로그램을 실행 중입니다(shebang의 도움으로).
하지만 당신이 달릴 때
bash foo.sh
기술적으로는 bash 프로그램(/bin/bash 또는 /usr/bin/bash)을 실행하고 있습니다.
안전이 걱정된다면. 사용자가 foo.shfoo.sh에 대한 읽기 액세스 권한을 갖고 있고 해당 내용을 bar.shfoo.sh 에 복사했다고 가정합니다 execute access. 따라서 어떤 경우에도 사용자가 .sh파일을 읽을 수 있으면 쉽게 실행할 수 있습니다.
답변3
이는 "한 사람의 데이터는 다른 사람의 프로그램이다"라는 옛말의 결과일 뿐입니다. 컴퓨터는 폰 노이만 아키텍처를 기반으로 구축되었습니다. 즉, "이것은 실행 파일이고 다른 것은 실행 파일이 아닙니다"라고 말하는 파일에 고유한 내용이 없습니다. 귀하가 작성한 모든 산문 텍스트는 적절한 통역사가 해석할 때 프로그램으로 작동할 수 있습니다.
따라서 파일에 숨겨야 할 정보가 포함되어 있는 경우 읽기 방지를 설정해야 합니다. 강제 보호는 도움이 되지 않습니다. 보호를 수행하지만 보호를 읽지 않는 컴파일된 프로그램이 있더라도 쉽게 실행할 수 있습니다. 복사하고 복사본에 대한 실행 권한을 설정하면 작업이 완료됩니다.
따라서 안전을 원한다면 파일과 파일이 위치한 디렉터리에서 읽기 권한을 제거해야 하지만 실행 권한은 제거해야 합니다.