Чому джерелу Баша не потрібен біт виконання?

За допомогою Bash sourceможна виконати сценарій без набору бітів виконання. Це задокументоване та очікуване поведінка, але чи не проти використання біта виконання?

Я знаю, sourceце не створює підзаголовок.

Баш - перекладач; він приймає вклад і робить все, що хоче. Тут не потрібно прислухатися до виконуваного біта. Фактично, 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

Це дещо аналогічно пошуку вихідного коду Bash у Bash, за винятком того, що ld.soце інтерпретатор, а код, який він виконує, є машинним кодом у форматі ELF.

sourceабо еквівалентна, але стандартна крапка. не виконує скрипт, а читає команди з файлу сценарію, а потім виконує їх, рядок за рядком, у поточному середовищі оболонки.

Там немає нічого проти використання виконання біта, тому що оболонка тільки потрібно прочитати дозвіл на читання вмісту файлу.

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

Виконаний біт (на відміну від решти) для нечистових та нечутливих файлів не є надто механізмом захисту. Все, що ви можете прочитати, ви можете запустити побічно, і Linux дозволить вам побічно читати все, що ви можете запустити, але не безпосередньо прочитати (цього має бути достатньо, щоб пробити дірку в концепції не встановленого (g) uid x-біта, який є a захід безпеки).

Це більше зручності: дозвольте системі запустити його безпосередньо для мене, якщо біт встановлений, інакше мені потрібно це зробити побічно ( bash the_script;або деякий злом, щоб отримати зображення пам'яті виконуваного дозволу без читання ).

Ви можете встановити це для зручності, якщо ви маєте намір як вводити, так і виконувати ваш ресурс.

Мабуть, однак, багато реалізаторів спільної бібліотеки поділяють ваше мислення, і, отже, багато систем вимагають, щоб спільні бібліотеки, які по суті є нативним еквівалентом оборотних ресурсів оболонок, були позначені виконуваними, щоб бути корисними. Див. Чому спільні бібліотеки виконують? .

Це гарне запитання! Unix використовує виконуваний біт для розмежування програм і даних. ОС не вимагає біт виконання, оскільки джерело джерела не передається в ОС для виконання як новий процес. Але оболонка розглядає джерело джерела як програму і шукатиме $PATHфайл, який ви хочете отримати. Отже, сама оболонка могла вимагати виконання дозволу на джерела файлів; але це не сталося

Питання, мабуть, виникло давно. Дизайн оболонки Борна став результатом "тривалої послідовності модифікацій, діалогу, обговорення" серед мешканців Bell Labs, і багато дизайнерських рішень протягом багатьох років обговорювали С. Р. Борн та інші. На жаль, мій швидкий погляд не знайшов дискусії щодо функції джерела (на мою захист важко це гугл). Я знайшов, що "". Команда не з'являється в цьому ранньому вступі до оболонки самим Борном, але вона присутня у більш зрілій версії версії 7 .

Відсутня влада, ось моя власна інтерпретація:

1. .Команди, він же source, в текстології включенні ефекту (як #includeв препроцесорів C) в вихідному код виконуючого сценарію або інтерактивної сесії. Як такий, включений файл, мабуть, не "виконується".

2. Філософія Unix завжди полягала в тому, щоб дати програмістам достатньо мотузки, щоб повіситися. Занадто велика кількість рук і довільних обмежень просто заважають. Лише зовсім недавно деякі розповсюдження rm -r /відмовляються робити те, що ви просите. (Ця команда говорить , rmщоб видалити всі на своєму комп'ютері. Не намагайтеся як корінь! Або ще краще, не зовсім.) Так що , можливо , Борн в співавт. щойно вирішив, що, намагаючись створити файл, ти вважатимеш, що ти робиш. Це також дозволяє уникнути зайвої роботи, і цикли мали багато часу.

Що стосується ОС, то файл, що містить скрипт оболонки, - це лише дані. Якщо ви передаєте ім'я такого файлу даних в sourceкоманду або передаєте його в командному рядку для виклику оболонки bash, все, що бачить ОС, - це рядок, який збігається з іменем файлу, що містить дані.

Як би біт виконання був би взагалі доречним у такому випадку?

Відмінність важлива, оскільки у вас може бути файл команд оболонки, який не є корисним як виконуваний файл, а корисний лише під час пошуку. Для цього файлу ви можете вимкнути біт виконання, і тоді він ніколи не буде доступний, якщо явно не буде вказано команду-джерело. Причиною такої речі є побічні ефекти на оболонці, з якої вона запущена. Для конкретного прикладу, у мене є сценарій під назвою fix_path, який переглядає та змінює шлях.

На всякий випадок, коли когось цікавлять подальші дослідження та / або уточнення: У майже сумісній з POSIX оболонці, впровадженій деякий час тому, внутрішня робота функцій 'exec_program ()' та 'buildin_source ()' є дуже зразковими. У цих функціях ви точно бачите, в чому різниця між ними:

https://github.com/rsenn/shish/blob/master/src/builtin/builtin_source.c

https://github.com/rsenn/shish/blob/master/src/exec/exec_program.c

в основному джерело пошуку може розглядатися як оболонка тимчасово перенаправляє свій внутрішній дескриптор файлу, звідки вона аналізує скрипт оболонки (термінал в інтерактивному режимі). так що це дуже схоже на переадресації , як <input_file.txtі >>append_to_something.listі їх просто потрібно відкривати і закривати файли.

тому виконання виконується execve()системним викликом, для якого біт виконання є обов'язковим.

Пригадую, я бачив деякі системи, які дозволяють виконувати бінарні файли ELF / a.out, але за допомогою виконання "/lib/ld-dynamic-linker.so" та з бінарною програмою (без файлу exec) в якості першого аргументу. Я вважаю, що це було на деяких машинах DEC Alpha або VAX (Можливо, це був SCO Unix?)

Інша точка зору:

Заданий скрипт в основному складається з вбудованих оболонок та програмних дзвінків. Вбудовані оболонки (з- sourceпоміж них) є частинами оболонки, і оболонка повинна бути виконана в першу чергу. Кожна названа програма (що це за ELF, інший скрипт із шебангом, що завгодно) має мати встановлений біт виконання, інакше вона не запуститься.

Тож це не проти використання біта виконання, оскільки нічого без біта виконання не буде працювати. Перевірка не відбувається для скрипта, який розміщено в цілому; воно виконується для кожної частини окремо, але це так.