Что изначально делал липкий бит при применении к файлам?

Нет, липкий бит не был похож на флаги set-UID или set-GID. Это не повлияло ни на какие изменения в учетных данных процесса.

Прилипающий бит делал текст программы «липким». Изначально это не было неправильным названием.

фон: разделы программных изображений и общий текст

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

Они сгруппированы в коллекции, известные как «секции», и имеют общепринятые названия.Машинный код и (иногда) константы образуют так называемый «текстовый» раздел изображения программы. Ненулевые инициализированные переменные аналогичным образом являются разделом «данных»; а переменные с нулевой инициализацией и неинициализированные - это "bss" (имя, которое само по себе имеет целую фольклорную историю).

Когда в процесс загружен исполняемый файл изображения программы, различные части - текст, данные и bss - инициализируются из содержимого файла изображения.

Особенностью раздела «текст» является то, что машинный код (и константы) почти всегда не записывается. Он потенциально может совместно использоваться в образах виртуальной памяти всех выполняемых процессов, в которые был загружен этот исполняемый файл образа. Точный сценарий, в котором можно поделиться текстом программы, выходит за рамки этого ответа и включает такие вещи, как идемпотентность исправления загрузчика и идентичность макета адресного пространства. Люди тоже могут писать книги на эту тему. ☺

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

липкий текст

Но можно еще лучше, чем общий текст. Очевидно, что если всегда выполняется хотя бы один процесс, который использует конкретный общий текстовый образ программы, ядро ​​может просто присоединить пространство виртуальной памяти новых процессов к существующему общему текстовому сегменту при запуске нового экземпляра программы.Почти всегда есть экземпляр (скажем) / bin / login или / bin / sh , выполняющийся где-то в системе среднего размера, поэтому новые экземпляры Программа входа в систему или оболочка по умолчанию могут просто присоединяться к загруженным копиям своих текстовых сегментов, которые ядро ​​уже загрузило в память.

Закрепленный текст расширяет эту идею для программирования изображений, в настоящее время не запущенных процессов . Если исполняемый файл изображения помечен как закрепленный текст, то ядро ​​сохраняет свой текстовый сегмент после выхода из последнего процесса, который его использовал; в надежде, что вскоре будет выполнен другой экземпляр программы, который можно будет просто присоединить к сегменту.

В ранних версиях Unix загруженные сегменты липкого текста выгружались на место для хранения подкачки, когда к ним не было присоединено ни одного процесса. (Позднее Unices перестали использовать для этого swap.) Вы также могли слышать об этом по имени сохраненный текст .

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

desuetude

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

Времена липких текстовых битов для образов исполняемых программ давно прошли. Например, явный флаг-маркер залипания текста для образов исполняемых программ считался устаревшим авторами 4.3BSD в середине 1980-х.

Дополнительная литература

• Морис Дж. Бах (1986). Дизайн операционной системы UNIX . Прентис-Холл. ISBN 9780132017992.