Bash를 사용하면 source실행 비트를 설정하지 않고도 스크립트를 실행할 수 있습니다. 이것은 문서화되어 있고 예상되는 동작이지만 실행 비트 사용에 위배되지 않습니까?
나도 알아요, 그것은 source서브 쉘을 생성하지 않습니다.
답변1
답변2
Bash는 통역사입니다. 입력을 받아들이고 원하는 모든 작업을 수행합니다. 실행 가능한 비트에 주의할 필요가 없습니다. 실제로 Bash는 이식 가능하며 실행 가능 비트에 대한 개념이 없는 운영 체제 및 파일 시스템에서 실행될 수 있습니다.
실행 가능 비트에 관심을 갖는 것은 운영 체제 커널입니다. exec예를 들어 Linux 커널은 noexec.
실행 가능 비트는 다소 임의적인 종류의 제어라는 점에 유의하십시오. 예를 들어, Linux x86-64 시스템에서는 다음과 같이 커널의 실행 비트 확인을 우회할 수 있습니다./lib/x86_64-linux-gnu/ld-linux-x86-64.so.2명시적 으로 인터프리터로 호출:
cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ls
ld.so이는 인터프리터이고 실행되는 코드가 ELF 형식의 기계 코드라는 점을 제외하면 Bash에서 Bash 소스 코드를 소싱하는 것과 다소 유사합니다 .
답변3
nonsetuid 및 nonsetguid 파일의 실행 가능 비트(나머지 파일과 달리)는 그다지 보안 메커니즘이 아닙니다. 읽을 수 있는 것은 무엇이든 간접적으로 실행할 수 있으며, Linux는 실행할 수 있지만 직접 읽을 수는 없는 모든 것을 간접적으로 읽을 수 있게 해줍니다. (이것은 non-set(g)uid x-bit 개념에 구멍을 뚫기에 충분합니다. 보안 조치).
이는 더 편리한 것입니다. 비트가 설정된 경우 시스템이 직접 실행하도록 하고, 그렇지 않으면 간접적으로 실행해야 합니다( bash the_script;또는 일부읽기 권한이 없는 실행 파일의 메모리 이미지를 얻기 위한 해킹).
인소싱 케이블을 인소싱하고 실행하려는 경우 편의를 위해 설정할 수 있습니다.
그러나 분명히 많은 공유 라이브러리 구현자는 귀하의 생각을 공유하므로 결과적으로 많은 시스템에서는 본질적으로 쉘 인소스 케이블과 기본적으로 동등한 공유 라이브러리를 사용 가능하도록 실행 가능으로 표시해야 합니다. 보다공유 라이브러리가 실행 가능한 이유는 무엇입니까?.
답변4
OS에 관한 한, 쉘 스크립트를 포함하는 파일은 단지 데이터일 뿐입니다. 이러한 데이터 파일의 이름을 source명령에 전달하거나 명령줄에서 bash 셸 호출에 전달하면 OS가 보는 모든 것은 데이터가 포함된 파일 이름과 일치하는 문자열뿐입니다.
이 경우 실행 비트는 어떤 관련이 있습니까?