Кроме рассмотренных выше битов (чтение,запись и "исполняемость"), которые устанавливаются раздельно по трем категориям юзеров, есть еще три бита доступа, которые можно отнести к файлу в целом, поскольку их действие не зависит от того какой юзер (в смысле из какой категории) пытается обратиться к файлу. Да и смысл этих битов состоит не в ограничении доступа к файлу (директории). Они изменяют некоторые свойства файлов или директорий.
Бит suid. Расшифровывается как Set user ID, переводится как "установить идентификатор юзера". Поскольку подходящего русскоязычного термина не существует, его обычно называют "суидный" бит, а файлы, на которых он установлен - "суидными".
Смысл его состоит в том, что если он установлен на файле, который является программой, то при выполнении эта программа автоматически меняет "эффективный userID" на идентификатор того юзера, который является владельцем этого файла. То есть, не зависимо от того - кто запускает эту программу, она при выполнении имеет права хозяина этого файла.
Обычно это делается для того, чтобы юзер мог выполнить действия, которые требуют привилегий root'а (например, поменять свой пароль). Естественно, что для этого владельцем такой программы должен быть юзер root.
Понятно, что такая программа является "потенциально опасной". В "нормальном" случае она не позволит обычному юзеру сделать то, что выходит за пределы его полномочий (например, программа passwd разрешит юзеру изменить только собственный пароль, но не пароли других юзеров). Но, даже незначительная ошибка в такой программе может привести к тому, что "злоумышленник" сможет заставит ее выполнить еще какие-нибудь действия, не предусмотренные автором программы. Кстати, большинство известных способов "взлома" системы заключаются не в том, чтобы узнать пароль root'а, а как раз в том, чтобы заставить какую-нибудь из "суидных" программ выполнять действия необходимые "взломщику".
Вообще говоря, использование "суидных" программ (когда они нужны и для чего) - достаточно обширная тема выходящая за рамки разговора о permissions. Замечу только, что это не единственный путь сменить "эффективный userID". Это можно сделать из самой программы, вызвав специальную системную функцию, но для этого программы должна уже иметь права root'а. То есть, ее должен запустить юзер root, или она должна быть "суидной", как сказано выше.
Возвращаясь к разговору о "правах доступа", надо сказать, что у такого файла permissions выглядят как **s****** (если еще и установлен бит x для владельца файла) или как **S****** (если бит x не установлен). Однако, ставить suid бит на неисполняемые файлы обычно не имеет смысла (по крайней мере в FreeBSD). Хотя, мне попадались программы, которые проверяли этот бит даже для текстовых файлов.
Также, это бит не несет никакого смысла если его поставить на директорию, хотя никто не запрещает это сделать.
Бит sgid. Расшифровывается как Set group ID, переводится как "установить идентификатор группы".
Эго смысл аналогичен смыслу предыдущего бита . Только меняется не идентификатор юзера, а идентификатор группы. То есть, при выполнении этого файла он имеет такие права как будто его запустил кто-то из группы, которая приписана к этому файлу.
Permissions такого файла выглядят как *****s*** (если установлен бит x для группы) или *****S** (если соответствующего бита x нет). Также как и в предыдущем случае, бит sgid для неисполняемых файлов никакого смысла не имеет.
А вот что касается бита sgid на директории...
Для FreeBSD (и других ветвей BSD) этот бит, опять же, не оказывает никакого
действия. Но в некоторых других Юниксах он означает, что, когда файлы
создаются в такой директории, в их атрибутах проставляется группа
та же, что и у директории. Другими словами, файлы, создаваемые в такой
директории "наследуют" группу от директории.
Бит sticky. Никак не расшифровывается, переводится как "липкий". :-)
Выглядит в permissions как ********t (если вместе с битом x для "всех
остальных") или ********T (если соответствующего бита x нет).
Для директорий его смысл заключается в том, что удалить файл из такой директории (или переименовать) может только владелец файла. Напомню, что в обычном случае (без такого бита) возможность удалять файлы (как и создавать) определяется правом записи (бит w) на директории. То есть, если какой-либо юзер принадлежит к категории, для которой разрешена запись в директорию, он может удалить в ней любой файл, независимо от атрибутов (владельца, группы, permissions) самого файла.
Применяют этот бит, обычно, на директориях, которые являются "публичными" (например, /tmp). Такие директории имеют права доступа, позволяющие всем юзерам создавать там свои файлы и удалять их. Однако, было бы неправильно, что любой другой юзер мог по ошибке или "из вредности" удалять файлы, к которым он не имеет никакого отношения. Для того, чтобы предотвратить возможность удаления файла "посторонним" юзером, как раз и служит sticky бит.
Этот бит может ставиться также на исполняемые файлы. В этом случае он означает, что файл, даже после завершения работы, должен оставаться в памяти (конечно, не в ОЗУ, а в swap'е).
Как говорится в документации, это полезно для "часто используемых исполняемых файлов общего пользования". К сожалению, реальных примеров таких файлов я не нашел. Возможно, практически он никем не используется.
Иван Паскаль pascal@tsu.ru