ответ на вопрос 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