Эта ссылка объясняет преимущества использования опции noexec при использовании mount . Однако в нем перечислено одно ограничение - если у меня есть скрипт на Perl/Python/shell или файл, начинающийся с #! и я попытаюсь выполнить его - я смогу сделать это независимо от того, предоставил ли я опцию или нет.
Есть ли способ предотвратить такое исполнение? Т.е. есть ли дополнительная опция для noexec которую я могу дать, и выполнение сценариев будет невозможно?
Здесь есть серьезное недоразумение. Давайте проясним эти вещи.
Прежде всего, указанное вами ограничение не так:
Тем не менее, когда скрипт (текстовый файл, который начинается со строки взрыва; т.е., строка, начинающаяся с
#!) дается некоторым оболочкам (bash), он запускает исполняемый файл, названный в этой строке (например,/usr/bin/perl), и подключает содержимое файла сценария к стандартному вводу этого исполняемого файла, который может отсутствовать на этом диске ,
Удивительно, но это объясняет возможность выполнения, несмотря на noexec. Я думаю, что спрашивающий там все понял неправильно, и это была не его вина! Одно неверное предположение в вопросе вызвало другое неправильное предположение в ответе.
Что тогда не так?
Чтобы получить некоторый контекст, давайте посмотрим, что происходит, когда вы пытаетесь связать 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 то это было бы разумным предположением.
Но…
Прочитайте, как работает #!шебанг работа? и обратите внимание, что один из ответов там изначально следовал мифу, а затем был исправлен.
Так что если у вас есть:
/mnt/foo/ с параметром noexec ,/mnt/foo/script.py который в противном случае исполняется (например, был вызван chmod -x … ),#!/usr/bin/python в качестве первой строки в скриптеи вы запускаете это так
/mnt/foo/script.py
тогда ваше ядро Linux не пропустит вас из-за noexec . Это случилось бы в этом другом вопросе, если бы монтирование там на самом деле не noexec ; но я считаю, что это не так.
Из комментариев:
"и попробуем его выполнить" Как? Запустив его напрямую или передав переводчику?
Запуск его напрямую означает:
/mnt/foo/script.py
Это будет соблюдать noexec как описано выше. Исполняемый файл - script.py .
Передача его переводчику означает:
python /mnt/foo/script.py
В этом случае исполняемым файлом является python . Не имеет значения, монтируется ли foo/ с помощью noexec ; не имеет значения, исполняется ли script.py вообще; Неважно, что такое Шебанг. Дело в том, что script.py не выполняется, он читается .
Пока пользователь может читать файл и запускать правильный интерпретатор, нет способа предотвратить передачу файла интерпретатору; но это не файл, который выполняется.