Здесь есть серьезное недоразумение. Давайте проясним эти вещи.
Прежде всего, указанное вами ограничение не так :
Однако, когда сценарий (текстовый файл, начинающийся со строки she-bang; т.е. строки, начинающейся с
#!) дается некоторым оболочкам (bash), он запускает исполняемый файл, названный в этой строке (например,/usr/bin/perl), и подключает содержимое файла сценария на стандартный ввод этого исполняемого файла, который может отсутствовать на этом диске.
Удивительно, но, кажется, объяснить способность выполнять, несмотря наnoexec . Я думаю, что спрашивающий там все понял неправильно, и это была не его вина! Одно неверное предположение в вопросе вызвало другое неправильное предположение в ответе.
Что тогда не так?
1. Привязка является специфической
Чтобы получить некоторый контекст, давайте посмотрим, что происходит, когда вы пытаетесь связать mount только для чтения. Возникает вопрос: почему mount не поддерживает параметр только для чтения для bind mounts? Вывод:
Для достижения желаемого результата нужно запустить две команды:
mount SRC DST -o bind mount DST -o remount,ro,bindБолее новые версии mount (util-linux> = 2.27) делают это автоматически при запуске
mount SRC DST -o bind,ro
Но когда вы пытаетесь использовать noexecвместо ro, вам все равно нужны две команды! В моем Kubuntu у меня есть util-linux 2.27.1-6ubuntu3.3и эта команда:
mount SRC DST -o bind,noexec игнорирует noexec, мне нужно перемонтировать. То же самое, если монтаж через /etc/fstab. Вы можете экспериментировать. В любое время проверьте с помощью простой mountкоманды, каковы фактические параметры.
Бьюсь об заклад, аскер думал, что крепление было с noexecопцией, но на самом деле это не так. Он или она смогли выполнить сценарий из предположительно точки noexecмонтирования. Это было странно, отсюда и вопрос.
Затем автор ответа интерпретировал это так, как если бы это была оболочка, которая читает shebang, вызывает другой исполняемый файл и не заботится о noexecсценарии. Если точка монтирования была действительно, noexecто это было бы разумным предположением.
Но…
2. Это распространенный миф, что ракушки читают шебанги; ядро делает
Прочитайте, как работает #! шебанг работа? и обратите внимание, что один из ответов там изначально следовал мифу, а затем был исправлен.
Так что если у вас есть:
- точка монтирования
/mnt/foo/сnoexecопцией, - скрипт,
/mnt/foo/script.pyкоторый в противном случае исполняется (например,chmod -x …был вызван), - Шебанг,
#!/usr/bin/pythonкак в первой строке сценария
и вы запускаете это так
/mnt/foo/script.py тогда ваше ядро Linux не позволит вам из-за noexec. Это произошло бы в этом другом вопросе, если бы монтаж был на самом деле noexecтам; но я считаю, что это не так.
3. Тем не менее, есть два способа «выполнить» скрипт
Из комментариев:
"и попробуем его выполнить" Как? Запустив его напрямую или передав переводчику?
Запуск его напрямую означает:
/mnt/foo/script.py Это будет чести, noexecкак описано выше. Исполняемый файл есть script.py .
Передача его переводчику означает:
python /mnt/foo/script.py В этом случае исполняемый файл есть python. Неважно, если foo/установлен с noexec; не имеет значения, script.pyявляется ли он исполняемым вообще; Неважно, что такое Шебанг. Суть script.pyне выполнена, она прочитана .
Пока пользователь может читать файл и запускать правильный интерпретатор, нет способа предотвратить передачу файла интерпретатору; но это не файл, который выполняется.