продолжение: почему файлы shebang не подходят?

334
ivo Welch

ответ на следующий вопрос https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts . есть очень хороший ответ Жиля. увы я этого не понимаю. ничто из описанного там не выглядит по-разному между исполняемыми файлами и интерпретируемыми.

  • сценарии имели условие замены файла гонки, но Unix-блокировка не нужна, чтобы это исправить. любой исполняемый файл C сначала читается, а затем исполняется. это можно сделать с помощью интерпретируемого кода так же легко, как и с исполняемым кодом. большинство сценариев (shell) не длиннее большинства исполняемых файлов на Си, поэтому их можно загрузить в первую очередь. тот факт, что более ранние реализации сначала читали одну строку, затем закрывали файл, а затем снова открывали его (и таким образом испытывали это состояние гонки), не являются внутренними. это просто случилось с древней реализацией. не легко ли это универсально исправить во всех реализациях Unix, читая весь интерпретируемый файл сценария?

  • время выполнения, необходимое для выполнения определенной функции, уязвимо, но это относится как к С-коду, так и к интерпретатору. скажем, сценарии оболочки или Python добавляют / имеют уязвимые среды выполнения?

  • любой (C) исполняемый файл может вызывать другие программы оболочки так же, как интерпретируемый язык. Программы, передаваемые друг другу, изначально претендовали на то, чтобы проходить через Unix, поэтому мы должны делать это часто.

все это более или менее указано в ответе Жиля, возможно, за исключением явного «сначала прочти все, потом второго выполни». вместо этого он описывает / dev / fd / эквивалентные реализации.

так что я все еще скучаю по нему. что по сути отличается? (Единственная функция безопасности, о которой я могу думать, это то, что, запретив suid-скрипты, мы затруднили noobs писать любые скрипты setuid.)

был ли комитет, который сделал и объяснил свое решение, скажем, для Ubuntu, где я могу прочитать мотивы?

/ IAW

0

2 ответа на вопрос

0
jjlin

Конечно, можно изменить реализацию, чтобы она была безопасной, но на практике это требует сотрудничества всех поставщиков Unix и большого переобучения пользователей. Если вы в состоянии координировать такие усилия, больше сил для вас. :) Альтернатива (например, придерживаться программ-оболочек setuid) может быть неудобной, но это не невыносимо.

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

спасибо, но это также ускользает от меня (каламбур?). любой дистрибутив Unix может сделать это. это не должно быть скоординировано. Creat, вероятно, должен быть таким же, как и для POSIX?! ivo Welch 9 лет назад 0
Это должно быть скоординировано. Никто не хочет писать сценарий, предназначенный для запуска setuid, а затем обнаруживает, что группа пользователей не может успешно запустить его, потому что их конкретная ОС не добавила поддержку. jjlin 9 лет назад 0
0
David Paige

Гораздо проще изменить скрипт оболочки, чем модифицировать двоичный файл. Никаких специальных инструментов, кроме редактора и доступа к файлу, не требуется. Даже sed работает, но это все еще редактор потоков.

Это имеет смысл с точки зрения безопасности, хотя. Вы можете запустить скрипт через sudo или su для получения root-прав. Вы всегда можете запустить программу suid внутри скрипта ....

Похожие вопросы