Липкий кусочек - Sticky bit

Эта статья посвящена концепции файловой системы. О технике арифметики с плавающей запятой см. Плавающая точка § Сложение и вычитание.

В вычисление, то липкий кусочек принадлежит пользователю право доступа флаг что может быть отнесено к файлы и каталоги на Unix-подобный системы.

Когда установлен бит закрепления каталога, файловая система обрабатывает файлы в таких каталогах особым образом, так что только владелец файла, владелец каталога или пользователь root можно переименовать или удалить файл. Без установленного липкого бита любой пользователь с разрешениями на запись и выполнение для каталога может переименовывать или удалять содержащиеся файлы, независимо от владельца файла. Обычно это устанавливается на / tmp каталог чтобы обычные пользователи не могли удалять или перемещать файлы других пользователей.

Современная функция липкого бита была представлена ​​в 4.3BSD.^{[обсуждать]} в 1986 году и встречается в большинстве современных Unix-подобных систем.

История

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

В настоящее время,^{[когда? ]} это поведение действует только в HP-UX и UnixWare. Солярис похоже, отказался от этого в 2005 году.^{[нужна цитата ]} Версия 4.4-Lite BSD сохранил старое поведение липких битов, но впоследствии было исключено из OpenBSD (начиная с версии 3.7) и FreeBSD (начиная с версии 2.2.1). Нет версии Linux когда-либо поддерживал это традиционное поведение; Linux выполняет кэширование исполняемых файлов так же, как и все файлы, поэтому повторное выполнение программы для очистки кеша не требуется.

использование

Чаще всего липкая насадка используется каталоги находящиеся в файловых системах для Unix-подобный операционные системы. Когда установлен бит закрепления каталога, файловая система обрабатывает файлы в таких каталогах особым образом, так что только владелец файла, владелец каталога или корень можно переименовать или удалить файл. Без установленного липкого бита любой пользователь с разрешениями на запись и выполнение для каталога может переименовывать или удалять содержащиеся файлы, независимо от владельца файла. Обычно это устанавливается на / tmp каталог чтобы обычные пользователи не могли удалять или перемещать файлы других пользователей. Эта функция была представлена ​​в 4.3BSD в 1986 году, и сегодня она присутствует в большинстве современных Unix-подобных систем.

Кроме того, Solaris (начиная с Solaris 2.5) определяет особое поведение, когда липкий бит установлен для неисполняемых файлов. файлы: эти файлы при доступе не будут кешированный посредством ядро. Обычно это устанавливается на файлы подкачки чтобы предотвратить удаление более важных данных из системного кеша при доступе к файлу. Он также иногда используется для сравнительный анализ тесты.^{[нужна цитата ]}

Липкий бит также устанавливается автомастерская чтобы указать, что файл еще не смонтирован. Это позволяет программам вроде ls игнорировать отключенные удаленные файлы.

Выдержки из страницы руководства о влиянии липкого бита на каталоги и файлы

Операционная система	Справочники	Файлы
AIX 5.2[1]	указывает, что только владельцы файлов могут связывать или отменять связь файлов в указанном каталоге.	устанавливает атрибут save-text.
Солярис 11[2]	Если каталог доступен для записи и для него установлен S_ISVTX (липкий бит), файлы в этом каталоге могут быть удалены или переименованы, только если выполняется одно или несколько из следующих условий (см. Unlink (2) и rename (2)): пользователь владеет файл, пользователь владеет каталогом, файл доступен для записи пользователем, пользователь является привилегированным пользователем.	Если обычный файл не является исполняемым и для него установлено значение S_ISVTX, предполагается, что файл является файлом подкачки. В этом случае системный кеш страниц не будет использоваться для хранения данных файла. Если […] установлен для любого другого файла, результаты не определены.
HP-UX[3]	Если для каталога задано значение […], непривилегированный пользователь не может удалять или переименовывать файлы других пользователей в этом каталоге.	[…] Предотвращает отказ системы от изображения области подкачки текстовой части файла при завершении работы последнего пользователя. Затем, когда следующий пользователь файла выполнит его, текст не нужно будет читать из файловой системы, его можно просто заменить, что сэкономит время.
Linux[4]	Когда […] установлен для каталога, файлы в этом каталоге могут быть отсоединены или переименованы только пользователем root, владельцем каталога или владельцем файла.	ядро Linux игнорирует липкий бит файлов.
FreeBSD[5]	Если […] установлен для каталога, непривилегированный пользователь не может удалять или переименовывать файлы других пользователей в этом каталоге.	Система FreeBSD VM полностью игнорирует липкий бит (S_ISVTX) для исполняемых файлов.
IRIX[6]	Если […] установлен в каталоге, то любые файлы, созданные в этом каталоге, будут принимать идентификатор группы каталога, а не идентификатор группы вызывающего процесса. mount (1M) может использоваться для включения этой функции независимо от режима каталога.	Если бит залипания, S_ISVTX, установлен в файле, который является динамическим загрузчиком для исполняемого файла ELF, тогда, когда исполняемый файл выполняется, адресные пространства старого процесса только для чтения будут доступны динамическому загрузчику в новом процессе. Это может значительно сократить время запуска программы. Установка липкого бита для любого другого файла не имеет никакого эффекта.
Mac OS X (Leopard)[7]	Каталог, для которого установлен «липкий бит», становится каталогом только для добавления […], в котором удаление файлов ограничено. Файл в прикрепленном каталоге может быть удален или переименован пользователем только в том случае, если у пользователя есть разрешение на запись в каталог, и пользователь является владельцем файла, владельцем каталога или суперпользователем. Эта функция полезна для каталогов, таких как / tmp, которые должны быть доступны для записи, но должны отказывать пользователям в лицензии на произвольное удаление или переименование файлов друг друга. Любой пользователь может создать липкий каталог.	Бит залипания не влияет на исполняемые файлы. Вся оптимизация того, остаются ли текстовые изображения резидентными в памяти, выполняется системой виртуальной памяти ядра.
NetBSD[8]	Каталог, для которого установлен «липкий бит», становится каталогом, в котором запрещено удаление файлов. Файл в прикрепленном каталоге может быть удален или переименован пользователем только в том случае, если у пользователя есть разрешение на запись в каталог, и пользователь является владельцем файла, владельцем каталога или суперпользователем. Эта функция успешно применяется к каталогам, таким как / tmp, которые должны быть доступны для записи, но должны отказывать пользователям в лицензии на произвольное удаление или переименование файлов друг друга.	NetBSD в настоящее время не обрабатывает обычные файлы, для которых специально установлен липкий бит, но это поведение может измениться в будущем.
OpenBSD[9]	Каталог с установленным `` липким битом '' накладывает ограничения на удаление файлов: файл в липком каталоге может быть удален или переименован пользователем только в том случае, если у пользователя есть разрешение на запись в каталог и пользователь является владельцем файла, владелец каталога или суперпользователь. Эта функция успешно применяется к каталогам, таким как / tmp, которые должны быть доступны для записи, но должны отказывать пользователям в лицензии на произвольное удаление или переименование файлов друг друга. Любой пользователь может создать липкий каталог. См. Chmod (1) для получения подробной информации об изменении файловых режимов.	Исторически сложилось так, что исполняемый совместно используемый файл с установленным битом закрепления не сразу удалялся из области подкачки после выполнения. Ядро скопировало текстовый сегмент файла для повторного использования в будущем, избегая, таким образом, перезагрузки программы. В современных системах это уже не так; текущая система виртуальной памяти отслеживает недавно использованные исполняемые файлы, что делает липкий бит для файлов избыточным. Бит залипания по-прежнему можно установить на файлы, но без какого-либо эффекта. Только суперпользователь может установить липкий бит для файла, хотя владелец файла может сбросить липкий бит.
SCO UnixWare[10]	Если каталог доступен для записи и липкий бит, S_ISVTX, установлен в каталоге, процесс может удалять или переименовывать файлы в этом каталоге, только если выполняется одно или несколько из следующих условий: эффективный идентификатор пользователя процесса такой же, как и идентификатор владельца файла эффективный идентификатор пользователя процесса такой же, как и идентификатор владельца каталога у процесса есть разрешение на запись в файл процесс имеет P_OWNER привилегия	Если 0410 а. выход в исполняемом файле установлен бит закрепления (бит режима 01000), операционная система не будет удалять текст программы из области подкачки при завершении последнего пользовательского процесса. Если для исполняемого файла 0413 a.out или ELF установлен бит закрепления, операционная система не удалит текст программы из памяти при завершении последнего пользовательского процесса. В любом случае, если установлен липкий бит, текст уже будет доступен (либо в области подкачки, либо в памяти), когда следующий пользователь файла выполнит его, что ускорит выполнение.

Примеры

Липкий бит можно установить с помощью chmod команда и может быть установлена ​​с помощью ее восьмеричного режима 1000 или ее символа т (s уже используется Setuid кусочек). Например, чтобы добавить бит в каталог / usr / местные / tmp, можно было бы ввести chmod + t / usr / местный / tmp. Или, чтобы убедиться, что в каталоге есть стандартные tmp разрешения, можно также ввести chmod 1777 / usr / местные / tmp.

Чтобы очистить его, используйте chmod -t / usr / местный / tmp или же chmod 0777 / usr / местный / tmp (последний также сбросит tmp каталог со стандартными разрешениями).

В Unix обозначение разрешений символьной файловой системы, липкий бит представлен буквой т в последнем месте символа, заменяя то, что в противном случае было бы Икс. Например, в Solaris 8 / tmp каталог, для которого по умолчанию установлен липкий бит, отображается как:

$ ls -ld / tmpdrwxrwxrwt 4 root sys 485 10 ноября, 06:01 / tmp

Если бит залипания установлен для файла или каталога без бит выполнения, установленного для другие категория (не-пользователь-владелец и не-владелец группы), указывается с большой буквы Т (заменяя то, что в противном случае было бы -):

# ls -l тест-rw-r - r-- 1 root anygroup 0 10 ноя, 12:57 test# chmod + t тест; ls -l тест-rw-r - r-T 1 root anygroup 0 10 ноября, 12:57 test

Смотрите также

• chmod
• Setuid

Рекомендации

1. «Архивная копия». Архивировано из оригинал на 2005-01-18. Получено 2009-01-19.
2. «Сводка - раздел 2 страниц руководства: Системные вызовы». Docs.oracle.com. 2011-11-01. Получено 2014-04-10.
3. [1] В архиве 20 ноября 2007 г. Wayback Machine
4. "chmod (1) - страница руководства Linux". Man7.org. Получено 2014-04-10.
5. "chmod - FreeBSD". Nixdoc.net. 1993-06-04. Получено 2014-04-10.
6. "chmod - IRIX / стандартный /". Nixdoc.net. Получено 2014-04-10.
7. «Библиотека разработчика Mac». Developer.apple.com. Получено 2014-04-10.
8. "липкие - страницы руководства NetBSD". Netbsd.gw.com. 2011-05-10. Получено 2014-04-10.
9. "Ручные страницы: липкие". Openbsd.org. 2014-02-14. Получено 2018-02-04.
10. "chmod (2)". Uw714doc.sco.com. 2004-04-25. Получено 2014-04-10.

внешняя ссылка

• Разрешения для файлов и каталогов Unix, 2010, Уэйн Поллок, архивировано 3 февраля 2012 г.