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

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

В ответе AskUbuntu ответчик написал, что « зацепки обычно относятся к каталогам» . Я заметил, что на самом деле современные системы на практике, кажется, никогда не применяют его к файлам, но давным-давно обычным делом было применение к файлам (образа исполняемой программы), а не к каталогам. (Когда дело доходит до нехватки современного использования файлов, возникает связанный с этим вопрос: Является ли залипание не используемым в современных файловых системах .)

Это вызвало вопрос:

Что сделал прикрепленный бит к исполняемому файлу? Было ли это как setuid тогда?

Обратите внимание на прошедшее время. Это не как липкий бит работает? в настоящее время. Это то, как это работало тогда.

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

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

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

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

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

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

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

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

липкий текст

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

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

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

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

устарелость

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

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

дальнейшее чтение

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