Bash의 소스 코드에 실행 비트가 필요하지 않은 이유는 무엇입니까?

source또는 동등하지만 표준가리키다.스크립트를 실행하지는 않지만읽다명령을 스크립트 파일에 저장하고 현재 쉘 환경에서 한 줄씩 실행합니다.

쉘은 실행 비트만 사용하면 되기 때문에 실행 비트를 사용하는 것에 반대할 것은 없습니다.읽다파일의 내용을 읽을 수 있는 권한입니다.

실행 비트는 실행하는 경우에만 필요합니다.달리기스크립트. 이 쉘은 fork()새로운 프로세스를 사용합니다.execve()이 함수는 스크립트에서 일반 실행 파일이어야 하는 새로운 프로세스 이미지를 생성합니다.

Bash는 인터프리터입니다. 입력을 받아 원하는 대로 수행합니다. 실행 가능한 비트에는 주의를 기울일 필요가 없습니다. 실제로 Bash는 이식 가능하며 실행 가능한 비트에 대한 개념 없이 운영 체제와 파일 시스템에서 실행될 수 있습니다.

실행 가능한 비트를 관리하는 것은 운영 체제 커널입니다. exec예를 들어, Linux 커널은 작업을 수행할 때 파일 시스템이 noexec옵션으로 마운트되지 않았는지 확인하고, 프로그램 파일의 실행 가능 비트를 확인하고, SELinux 또는 AppArmor와 같은 보안 모듈에서 부과하는 모든 요구 사항을 적용합니다.

실행 가능 비트는 다소 임의적인 컨트롤입니다. 예를 들어, 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 소스 코드를 얻는 것과 다소 유사합니다 .

nonsetuid 및 nonsetguid 파일의 실행 가능 비트(다른 비트와 달리)는 보안 메커니즘이 아닙니다. 읽을 수 있는 모든 것, 간접적으로 실행할 수 있습니다. Linux에서는 실행할 수 있지만 직접 읽을 수 없는 모든 것을 간접적으로 읽을 수 있습니다. (이것은 set(g)uid가 아닌 x 비트가 구멍이라는 개념을 깨기에 충분합니다. ) 안전 조치).

이것이 더 편리합니다. 비트가 설정되어 있으면 시스템이 직접 실행하도록 하고, 그렇지 않으면 간접적으로 실행해야 합니다( bash the_script;또는 일부해커는 읽기 권한 없이 실행 파일의 메모리 이미지를 획득합니다.).

비자원을 내부화하고 실행하려는 경우 편의를 위해 이를 설정할 수 있습니다.

그러나 분명히 많은 공유 라이브러리 구현자가 귀하의 아이디어에 동의하므로 많은 시스템에서 사용하려면 공유 라이브러리(본질적으로 쉘 인소스 케이블과 기본적으로 동일함)를 실행 가능으로 표시해야 합니다. 바라보다공유 라이브러리가 실행 가능한 이유는 무엇입니까?.

운영 체제에서는 쉘 스크립트가 포함된 파일이 단지 데이터일 뿐입니다. 이러한 데이터 파일의 이름을 명령에 전달하거나 source명령줄에서 bash 셸 호출에 전달하면 운영 체제가 보는 모든 것은 데이터가 포함된 파일 이름과 일치하는 문자열뿐입니다.

이 경우 실행 비트의 관련성은 무엇입니까?