ответ на следующий вопрос 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