Бит suid.
Бит suid. Расшифровывается как Set user ID, переводится как "установить идентификатор юзера". Поскольку подходящего русскоязычного термина не существует, его обычно называют "суидный" бит, а файлы, на которых он установлен - "суидными".
Смысл его состоит в том, что если он установлен на файле, который является программой, то при выполнении эта программа автоматически меняет "эффективный userID" на идентификатор того юзера, который является владельцем этого файла. То есть, не зависимо от того - кто запускает эту программу, она при выполнении имеет права хозяина этого файла.
Обычно это делается для того, чтобы юзер мог выполнить действия, которые требуют привилегий root'а (например, поменять свой пароль). Естественно, что для этого владельцем такой программы должен быть юзер root.
Понятно, что такая программа является "потенциально опасной". В "нормальном" случае она не позволит обычному юзеру сделать то, что выходит за пределы его полномочий (например, программа passwd разрешит юзеру изменить только собственный пароль, но не пароли других юзеров). Но, даже незначительная ошибка в такой программе может привести к тому, что "злоумышленник" сможет заставит ее выполнить еще какие-нибудь действия, не предусмотренные автором программы. Кстати, большинство известных способов "взлома" системы заключаются не в том, чтобы узнать пароль root'а, а как раз в том, чтобы заставить какую-нибудь из "суидных" программ выполнять действия необходимые "взломщику".
Вообще говоря, использование "суидных" программ (когда они нужны и для чего) - достаточно обширная тема выходящая за рамки разговора о permissions. Замечу только, что это не единственный путь сменить "эффективный userID". Это можно сделать из самой программы, вызвав специальную системную функцию, но для этого программы должна уже иметь права root'а. То есть, ее должен запустить юзер root, или она должна быть "суидной", как сказано выше.
Возвращаясь к разговору о "правах доступа", надо сказать, что у такого файла permissions выглядят как **s****** (если еще и установлен бит x для владельца файла) или как **S****** (если бит x не установлен). Однако, ставить suid бит на неисполняемые файлы обычно не имеет смысла (по крайней мере в FreeBSD). Хотя, существуют программы, которые проверяли этот бит даже для текстовых файлов. Также, это бит не несет никакого смысла, если его поставить на директорию, хотя никто не запрещает это сделать.
Бит sgid
Бит sgid. Расшифровывается как Set group ID, переводится как "установить идентификатор группы".
Эго смысл аналогичен смыслу предыдущего бита. Только меняется не идентификатор юзера, а идентификатор группы. То есть, при выполнении этого файла он имеет такие права, как будто его запустил кто-то из группы, которая приписана к этому файлу.
Permissions такого файла выглядят как *****s*** (если установлен бит x для группы) или *****S** (если соответствующего бита x нет). Также как и в предыдущем случае, бит sgid для неисполняемых файлов никакого смысла не имеет.
Что касается бита sgid на директории...
Для FreeBSD (и других BSD-систем) этот бит, опять же, не оказывает никакого действия. Но в некоторых других Unix-системах он означает, что, когда файлы создаются в такой директории, в их атрибутах проставляется группа та же, что и у директории. Другими словами, файлы, создаваемые в такой директории "наследуют" группу от директории.
Бит sticky
Бит sticky. Никак не расшифровывается, переводится как "липкий".
Выглядит в permissions, как ********t (если вместе с битом x для "всех остальных") или ********T (если соответствующего бита x нет).
Для директорий его смысл заключается в том, что удалить файл из такой директории (или переименовать) может только владелец файла. Напомню, что в обычном случае (без такого бита) возможность удалять файлы (как и создавать) определяется правом записи (бит w) на директории. То есть, если какой-либо юзер принадлежит к категории, для которой разрешена запись в директорию, он может удалить в ней любой файл, независимо от атрибутов (владельца, группы, permissions) самого файла.
Применяют этот бит, обычно, на директориях, которые являются "публичными" (например, /tmp). Такие директории имеют права доступа, позволяющие всем юзерам создавать там свои файлы и удалять их. Однако было бы неправильно, что любой другой юзер мог по ошибке или "из вредности" удалять файлы, к которым он не имеет никакого отношения. Для того чтобы предотвратить возможность удаления файла "посторонним" юзером, как раз и служит sticky бит.
Этот бит может ставиться также на исполняемые файлы. В этом случае он означает, что файл, даже после завершения работы, должен оставаться в памяти (конечно, не в ОЗУ, а в swap).
Это полезно для часто используемых исполняемых файлов общего пользования. На практике такие файлы встречаются очень редко. Возможно, практически он никем не используется.
Для файлов
Обычно права на файл (например, для "всех остальных") устанавливаются
--- никаких прав (нельзя ни читать, ни изменять содержимое)
r-- только чтение
rw- и чтение и запись (изменение) файла.
Если файл является "исполняемым", то права могут выглядеть
--- опять же, никаких прав (читать нельзя, запускать нельзя)
r-x можно запустить файл-задачу на выполнение
rwx можно не только запустить, но и что-нибудь в нем поменять
Остальные сочетания (например -w- или --x) кажутся бессмысленными.
Однако, это не всегда так. Рассмотрим подробнее.
Права -w- означают, что юзер из соответствующей категории не может прочитать этот файл, но может в него писать.
Конечно, для "исполняемого" файла это сочетание бессмысленно (запустить как задачу нельзя, но "покорежить" что-нибудь внутри - пожалуйста).
Однако, если этот файл представляет собой что-то вроде "лога" или почтового ящика, то такие permissions могут иметь смысл. Например, вы допускаете, что другие юзеры (или какие-нибудь программы-автоматы) будут дописывать сюда свои "донесения", но не хотите, чтобы те же юзеры могли посмотреть - что туда написали другие.
Правда, при этом никто не мешает тем же юзерам просто не читая, записать в этот файл что-нибудь, удалив при этом все старое содержимое файла. Или даже скопировать туда файл нулевой длины (или /dev/null), при этом, естественно, вообще никакого "содержимого" у вашего файла не станет. Однако, чтобы предотвратить такую ситуацию можно поставить на тот же файл флаг "только дозапись". Он не помешает вам читать свой файл, а другим юзерам дописывать в него что-нибудь. Правда, не даст даже вам стирать из файла все лишнее или удалить файл, пока вы не "снимите" флаг.
Теперь посмотрим на исполняемые файлы.
Права --x на самом деле вполне законная комбинация. Она означает, что запустить эту задачу можно (и получить от нее какой-то результат). Нельзя только скопировать этот файл себе или "залезть" в него отладчиком.
Поэтому, такие permissions даже полезны, если вы хотите сохранить свою "интеллектуальную собственность". Комбинация -wx, пожалуй, смысла не имеет (как и просто -w- на исполняемом файле). Вы просто даете возможность изменить содержимое, причем "вслепую" (поскольку посмотреть это содержимое нельзя). Результатом может быть только порча вашего файла.
Также можно отнести к бессмысленным и права r-- на исполняемом файле. Если вы хотите таким способом "подразнить" кого-то (вот есть такой файл, можно посмотреть - как он внутри устроен, а выполнить нельзя), то не обольщайтесь. Другой юзер спокойно может скопировать этот файл себе, при этом он становится полноправным владельцем полученной копии. После этого он поставит на свою копию такие права, какие ему захочется и, все-таки, запустит его.
Для директорий
Для директорий обычно права доступа устанавливаются
--- никаких прав
r-x нормальные права для "посещения" директории, но без права изменения (создавать/удалять/переименовывать файлы)
rwx полный доступ (делай там что хочешь)
Имеет ли смысл устанавливать какие-либо другие сочетания?
Ну, во-первых, если отсутствует бит доступа --x (доступ к содержимому), то любая комбинация из двух остальных ничего полезного не даст.
Комбинация r-- даст возможность получить список файлов в этой директории, например командой ls, и не более того. Причем посмотреть можно будет только имена файлов, а такие подробности, как владелец/группа/permissions будут недоступны. В такую директорию нельзя "войти" командой cd. И, даже если внутри нее поддиректории имеют вполне нормальные права доступа (например, r-x), попасть в них будет невозможно.
Комбинации -w- и rw- имеют еще меньше смысла. Все равно, изменить что-нибудь в директории с такими правами доступа не удастся.
А вот сочетания --x и -wx на самом деле вполне осмысленны.
Таким способом можно сделать "полусекретную" директорию. "Секретность" ее заключается в том, что никто посторонний не сможет посмотреть - что за файлы и директории в ней находятся. Но, если вы своим друзьям сообщите - как называется файл находящийся там, они смогут без проблем его взять оттуда или посмотреть его прямо на месте.
Аналогично и с поддиректориями. Если вы не хотите, чтобы кто-нибудь просто "бродя" по вашим директориям наткнулся на директорию с "секретным" содержанием, но, в тоже время, не против чтобы некоторые близкие друзья могли туда "захаживать" и знакомится с новыми пополнениями, "спрячьте" свои "приватные" директории в директорию (например private) с доступом --x. Тогда ваши друзья смогут попасть в нужную поддиректорию, указав полный путь (cd private/pictures), а случайные посетители ее просто не найдут (если, конечно, этот посетитель не root).
Конечно, "секретность" в этом случае будет не полной, поскольку, если посторонний каким-то образом узнает правильное название файла или поддиректории, то получит те же возможности, что и "близкие друзья".
Права -wx отличаются от предыдущего тем, что "доверенным лицам" можно писать в эту директорию. Они могут скопировать туда файл, удалить (если, конечно, знают его точное название) и т.п. Опять же, посторонний сможет разве что записать туда файл, который вы не просили. Удалить там что-нибудь или переименовать, не зная названий файлов (и поддиректорий), он не сможет.
И, напоследок, еще один нестандартный случай, который касается распределения прав по категориям юзеров. Обычный порядок назначения прав различным категориям на файл или директорию
владелец - полные права (rwx)
группе доверенных лиц - тоже самое, но без права изменения (r-x)
всем остальным - никаких прав (---)
Вообще-то, обычно права назначаются даже еще проще. Поскольку, группы составляет root и рядовые юзеры, как правило, не выбирают себе соседей по группе, то их файлы и директории имеют одинаковые "допуски" для группы и "всех остальных". Например, для "несекретных" файлов (директорий) - rwxr-xr-x, а те, которые владелец хочет оградить от посторонних rwx------.
Но в данном случае речь не об этом. Что будет, если "всем остальным" дать доступ, пусть и ограниченный, а для группы "особо приближенных" - наоборот убрать (выглядеть это будет примерно так - rwx---r-x)?
Тогда группа, приписанная к файлу, превратится из группы "особо допущенных" в группу "особо нелюбимых". То есть некий "черный список", куда можно занести (естественно, сделать это может только root) всех тех, кто не пользуется доверием. Обратите внимание, что система, проверяя права конкретного юзера по отношению к файлу, сначала проверяет - не является ли он владельцем, потом - не входит ли он в группу, а уже после этого относит его ко "всем остальным". Так что, даже если "все остальные" имеют допуск к файлу, но юзер имел несчастье попасть в соответствующую группу, к нему будут применяться права доступа группы.
Трудно судить - можно ли извлечь из этого какую-то пользу. Тем более, что составить "черный список" может только root. И, кроме того, не забудьте, что количество групп, в которые может входить юзер, ограничено, поэтому не стоит без особой надобность "плодить" дополнительные списки. Но, во всяком случае, возможность поступить таким образом есть.
Кроме уже рассмотренных атрибутов (владелец, группа, "права доступа"), существует еще один атрибут, который ограничивает возможные действия с файлом - "набор флагов". Кстати, по умолчанию команда ls флаги не показывает (и большинство "файлменеджеров" - тоже). Для того, чтобы она их показала, надо указать ключ -lo. С помощью флагов можно запретить изменять содержимое файла, его название или и то и другое.
Флаги являются более "сильнодействующим средством" чем permissions. Они действуют одинаково для всех юзеров, не разделяя их на категории. Более того, их действие не может игнорировать и владелец файла и даже root. Единственное отличие владельца и root'а от прочих пользователей в том, что они могут убрать флаги с файла (и то не всегда) и только потом уже делать то, что им хочется.
Рассмотрим их подробнее.
Флаги делятся на две группы "юзерские" флаги и "суперюзерские". Разница в том, что "юзерские" может поставить и убрать как root, так и владелец файла, а ставить/убирать "суперюзерские" может только root.
На самом деле, "снятие" флагов - вопрос более сложный. Он зависит от того, в каком "режиме безопасности" находится система. Но об этом немного позднее.
По своему назначению флаги делятся на
append - разрешается только "дописывать" файл (естественно, файл должен также иметь permssion "w"). Без этого флага, если юзеру из соответствующей категории разрешается писать в файл, он может как добавить что-либо к содержимому файла, так и "убавить", то есть стереть часть содержимого. При установленном флаге append, любой юзер (даже root) сможет только добавить что-нибудь в конец файла, но не сможет ничего изменить в уже имеющемся содержимом.
Если этот флаг поставить на директорию, то в ней можно создавать файлы (или копировать туда файлы из других директорий), но нельзя удалять или менять их названия. Естественно, на сами файлы действие флага не распространяется.
nounlink - файл (или директорию) нельзя удалить или переименовать, даже если права, установленные на директории (в которой находится файл) это позволяют. В то же время, этот флаг не запрещает менять содержимое файла (если, конечно, permissions это позволяют).
immutable или change - "ничего нельзя". То есть, файл (директорию) нельзя ни удалить, ни переименовать, ни изменить содержимое. Опять же, если это флаг стоит на директории, то на файлы (в ней содержащиеся) его действие не распространяется. То есть, вы не сможете ни добавить, ни убрать файл в директории, но менять содержимое самих файлов это флаг не запретит.
Как уже говорилось, эти три флага существуют в двух вариантах - "юзерские" и "суперюзерские". То есть, на самом деле их шесть
три "юзерских" - uappend, uunlink и uimmutable
и три "суперюзерских" - sappend, sunlink и simmutable.
Вообще-то, существует еще два "непарных" флага. Это флаги
Эти флаги проверяются только некоторыми конкретными программами. Например, флаг nodump сообщает программе dump, что этот файл не надо сохранять в архиве. (Подробнее о программе dump вы можете прочитать в соответствующем man - man dump).
Сopyright © 2000. Андрей Фёдоров
http://www.anriintern.com/computer/freebsd/
Назад | Содержание | Вперед