☰

Почему исходному коду Bash не нужен бит выполнения?

tag-icon • tag-icon bash permissions executable source conventions
Почему исходному коду Bash не нужен бит выполнения?

С Bash sourceвозможно выполнить скрипт без установленного бита выполнения. Это задокументированное и ожидаемое поведение, но разве это не противоречит использованию бита выполнения?

Я знаю, это sourceне создаёт подоболочку.

решение1

sourceили эквивалент, но стандартныйточка.не выполнять скрипт, ночитатькоманды из файла скрипта, а затем выполнить их строка за строкой в ​​текущей среде оболочки.

Нет ничего против использования бита исполнения, потому что оболочке нужно толькочитатьразрешение на чтение содержимого файла.

Бит выполнения требуется только тогда, когда выбегатьскрипт. Здесь оболочка будет fork()новый процесс, затем используяexecve()функция создания нового образа процесса из скрипта, который должен быть обычным исполняемым файлом.

решение2

Bash — это интерпретатор; он принимает ввод и делает все, что хочет. Ему не нужно обращать внимание на исполняемый бит. Фактически, Bash является переносимым и может работать на операционных системах и файловых системах, которые не имеют никакого понятия об исполняемом бите.

Что заботится об исполняемом бите, так это ядро ​​операционной системы. Когда ядро ​​Linux выполняет exec, например, оно проверяет, что файловая система не смонтирована с 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

Это в некоторой степени аналогично извлечению исходного кода Bash из Bash, за исключением того, что ld.soэто интерпретатор, а код, который он выполняет, представляет собой машинный код в формате ELF.

решение3

Исполняемый бит (в отличие от остальных) в файлах non-setuid и nonsetguid не является механизмом безопасности. Все, что вы можете прочитать, вы можете запустить косвенно, и Linux позволит вам косвенно прочитать все, что вы можете запустить, но не можете прочитать напрямую (этого должно быть достаточно, чтобы пробить дыру в концепции non-set(g)uid x-bit как меры безопасности).

Это больше для удобства: пусть система запустит его для меня напрямую, если бит установлен, в противном случае мне придется сделать это косвенно ( bash the_script;или как-тохакерская попытка получить образ памяти исполняемого файла, не имеющего разрешения на чтение).

Вы можете установить его для удобства, если вы собираетесь как размещать внутри источника, так и выполнять свой внутренний источник.

Однако, судя по всему, многие разработчики общих библиотек разделяют ваши взгляды, и, следовательно, многие системы требуют, чтобы общие библиотеки, которые по сути являются собственным эквивалентом внутренних ресурсов оболочки, были помечены как исполняемые, чтобы их можно было использовать. СмотритеПочему общие библиотеки являются исполняемыми?.

решение4

С точки зрения ОС, файл, содержащий скрипт оболочки, — это просто данные. Если вы передадите имя такого файла данных команде sourceили передадите его в командной строке вызову оболочки bash, все, что увидит ОС, — это строка, которая случайно совпадает с именем файла, содержащего данные.

Какое значение в таком случае будет иметь бит выполнения?

Связанный контент