Что означает флаг NOEXEC при монтировании каталогов на RHEL?

Я пытаюсь понять флаг NOEXEC при монтаже.

У меня проблема с выполнением в каталоге / tmp на чужой машине, к которой у меня нет доступа к atm, где каталог / tmp смонтирован на диске, отличном от '/', и присутствует NOEXEC. Я хотел попытаться воссоздать этот сценарий на моей машине, но у меня нет второго жесткого диска. Я попытался сделать следующую команду:

mount --bind /test1 /test2

Затем я удалил bindфлаг и добавил NOEXECв / etc / fstab. Затем я создал файл в / test2 с именем test.sh, где он просто повторяет «привет мир». Я пытаюсь запустить его, и он говорит, что «разрешение отказано». Затем я побежал chmod 777 test.shи смог выполнить файл просто отлично. Я думал, что флаг NOEXEC не должен позволять мне выполнять что-либо?

Разве это mount --bind /test1 /test2не то же самое, что монтаж с совершенно другого физического диска? Как в / test1 и / test2 находятся на разных дисках?

— user972276
источник

Я подозреваю, что вы можете стать жертвой какой-то особенности привязки. Смотрите этот ответ .

— Камиль Мачоровски

Параметр «NOEXEC» в mountкоманде не разрешает выполнение исполняемых двоичных файлов в смонтированной файловой системе ¹ . Однако когда сценарий (текстовый файл, начинающийся со строки she-bang; т.е. строки, начинающейся с #!) передается некоторым оболочкам (bash), он запускает исполняемый файл, названный в этой строке (например, /usr/bin/perl), и передает путь сценария оболочки в качестве первого аргумента. Фактический интерпретатор может не находиться в этой точке монтирования.
__________
¹ Команда mountобычно монтирует файловую систему . (Возможно, возврат в петлю или bindмонтирование могут рассматриваться как исключение из этой общности.) В некоторых случаях (например, /tmp) эта файловая система будет содержать только один каталог.

— KJ4IPS
источник

Итак, хотя файл sh находится в / test2, он выполняется в / bin / sh, а не / test2? На другом компьютере есть процесс Java, который записывает сценарии оболочки в каталог / tmp и затем выполняет их. Я думаю, что я помню сценарии оболочки, которые он создает, #!/bin/shвверху. Я не знаю, как выполняется сценарий оболочки, кроме как через Java и ссылки / bin / sh. Если он ссылается на / bin / sh и каталог bin имеет права на выполнение, почему сценарии оболочки не будут выполняться так же, как в моем тесте?

— user972276

Это все, что связано с вызовом оболочки / программы, сценарии оболочки не являются ELF-файлами и не могут быть выполнены напрямую, однако некоторые оболочки не позволяют запускать сценарий на FS, на котором смонтирован NOEXEC, они просто умирают. Я не уверен, что поведение / bin / sh должно быть в этом случае. (Тем более, что я не знаю, какой из них вы используете, есть несколько вкусов).

— KJ4IPS

Если подумать, когда вы используете оболочку, система замечает #! и вызывает соответствующий интерпретатор (/ bin / bash /tmp/file.sh), но если бит Java просто вызывает (/tmp/file.sh), это не сработает.

— KJ4IPS

экземпляр java не находится в каталоге / tmp и должен был бы использовать интерпретатор для выполнения сценариев оболочки, верно? Если java не обладает такой встроенной функциональностью, это означает, что выполнение все равно не произойдет в каталоге / tmp.

— user972276

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

— Камиль Мачоровски