Posix acl linux
Обновлено: 05.07.2024
Преимущества списков контроля доступа
Традиционно файловый объект в Linux связан с тремя наборами разрешений. Эти наборы включают права на чтение (r), запись (w) и выполнение (x) для каждого из трех типов пользователей — владельца файла, группы и других пользователей. В дополнение к этому можно установить установленный идентификатор пользователя, установить идентификатор группы и липкий бит. Более подробное обсуждение этой темы можно найти в разделе Пользователи и права доступа Руководства пользователя.
Эта концепция бережливого производства полностью подходит для большинства практических случаев. Однако для более сложных сценариев или расширенных приложений системным администраторам раньше приходилось использовать ряд уловок, чтобы обойти ограничения традиционной концепции разрешений.
Списки управления доступом можно использовать в ситуациях, когда требуется расширение традиционной концепции разрешений на доступ к файлам. Они позволяют назначать разрешения отдельным пользователям или группам, даже если они не соответствуют первоначальному владельцу или группе-владельцу. Списки контроля доступа являются функцией ядра Linux и в настоящее время поддерживаются ReiserFS, Ext2, Ext3, JFS и XFS. С помощью ACL можно реализовать сложные сценарии без реализации сложных моделей разрешений на уровне приложения.
Преимущества списков ACL очевидны в таких ситуациях, как замена сервера Windows сервером Linux. Некоторые из подключенных рабочих станций могут продолжать работать под управлением Windows даже после миграции. Система Linux предлагает файловые службы и службы печати для клиентов Windows с Samba.
Учитывая, что Samba поддерживает списки контроля доступа, права пользователей можно настроить как на сервере Linux, так и в Windows с графическим пользовательским интерфейсом (только Windows NT и более поздние версии). С помощью winbindd можно даже назначать разрешения пользователям, которые существуют только в домене Windows без какой-либо учетной записи на сервере Linux. На стороне сервера отредактируйте списки контроля доступа с помощью getfacl и setfacl.
Определения
Класс пользователя Традиционная концепция разрешений POSIX использует три класса пользователей для назначения разрешений в файловой системе: владелец, группа-владелец и другие пользователи. Для каждого пользовательского класса могут быть установлены три бита разрешения, дающие разрешение на чтение (r), запись (w) и выполнение (x). Введение в концепцию пользователя в Linux представлено в Руководстве пользователя в разделе Пользователи и права доступа. ACL доступа Разрешения пользователей и групп на доступ ко всем типам объектов файловой системы (файлам и каталогам) определяются с помощью ACL доступа. ACL по умолчанию ACL по умолчанию можно применять только к каталогам. Они определяют разрешения, которые объект файловой системы наследует от своего родительского каталога при его создании. Запись ACL Каждый ACL состоит из набора записей ACL. Запись ACL содержит тип (см. Таблицу B.1), квалификатор пользователя или группы, к которым относится запись, и набор разрешений. Для некоторых типов записей квалификатор группы или пользователей не определен.
Обработка списков контроля доступа
В следующем разделе объясняется базовая структура ACL и ее различные характеристики. Взаимосвязь между ACL и традиционной концепцией разрешений в файловой системе Linux кратко демонстрируется с помощью нескольких рисунков. В двух примерах показано, как можно создать собственные списки ACL, используя правильный синтаксис. В заключение найдите информацию о том, как списки ACL интерпретируются операционной системой.
Структура записей ACL
Существует два основных класса списков ACL. Минимальный ACL просто содержит записи для типов владельца, группы-владельца и других, которые соответствуют обычным битам разрешений для файлов и каталогов. Расширенный ACL выходит за рамки этого. Он должен содержать запись маски и может содержать несколько записей типа именованный пользователь и именованная группа. В Таблице B.1 представлены сводные данные о различных типах возможных записей ACL.
Разрешения, определенные для владельца записей и другие, действуют всегда. За исключением записи маски, все остальные записи (именованный пользователь, группа-владелец и именованная группа) могут быть либо действующими, либо замаскированными. Если разрешения существуют в одной из вышеупомянутых записей, а также в маске, они действуют. Разрешения, содержащиеся только в маске или только в фактической записи, недействительны. Пример в таблице B.2 демонстрирует этот механизм.
Записи ACL и биты разрешения файлового режима
Рисунок B.1 и Рисунок B.2 иллюстрируют два случая: минимальный ACL и расширенный ACL. Рисунки разделены на три блока: в левом блоке показаны спецификации типов записей ACL, в центральном блоке показан пример ACL, а в правом блоке показаны соответствующие биты разрешений в соответствии с общепринятой концепцией разрешений, отображаемой командой ls -l. , например.
В обоих случаях разрешения класса владельца сопоставляются с владельцем записи ACL.Точно так же другие разрешения класса сопоставляются с соответствующей записью ACL. Однако сопоставление разрешений группового класса в обоих случаях отличается:
Рисунок B.1: Минимальный ACL: записи ACL по сравнению с битами разрешения-
В случае минимального ACL — без маски — разрешения класса группы сопоставляются с группой-владельцем записи ACL. Это показано на рисунке B.1.
Такой подход к сопоставлению обеспечивает беспрепятственное взаимодействие приложений с поддержкой ACL и приложений без поддержки ACL. Разрешения на доступ, которые были назначены с помощью битов разрешений, представляют собой верхний предел для всех других «тонких настроек», сделанных с помощью ACL. Все разрешения, не отраженные здесь, либо не были заданы в ACL, либо не действуют. Если биты разрешений изменены, это также отражается в соответствующем ACL и наоборот.
Каталог со списком контроля доступа
Обработка списков контроля доступа демонстрируется в три этапа на следующем примере:
<УЛ><ПР> Перед созданием каталога используйте команду umask, чтобы определить, какие права доступа должны быть замаскированы с самого начала:
Команда umask 027 устанавливает разрешения по умолчанию, предоставляя владельцу полный набор разрешений (0), запрещая группе доступ на запись (2) и не предоставляя другим пользователям вообще никаких разрешений (7). umask фактически маскирует соответствующие биты разрешения или отключает их. Подробнее см. на соответствующей справочной странице ( man umask ).
Это должно создать каталог mydir с разрешениями по умолчанию, установленными umask . Используйте следующую команду, чтобы проверить, все ли разрешения были назначены правильно:
drwxr-x-- . смокинг проект3. мой каталог
Вывод getfacl точно отражает сопоставление битов разрешений и записей ACL, как описано в B. Первые три строки вывода отображают имя, владельца и группу владельцев каталога. Следующие три строки содержат три записи ACL: owner, owner group и other. На самом деле, в случае этого минимального ACL команда getfacl не выдает никакой информации, которую вы не могли бы получить с помощью ls .
Ваша первая модификация ACL — это назначение разрешений на чтение, запись и выполнение дополнительному пользователю jane и дополнительной группе djungle .
Опция -m предлагает setfacl изменить существующий ACL. Следующий аргумент указывает записи ACL для изменения (несколько записей разделены запятыми). В последней части указывается имя каталога, к которому должны быть применены эти изменения.
Используйте команду getfacl, чтобы просмотреть полученный ACL.
В дополнение к записям, инициированным для пользователя jane и группы djungle, была создана запись в маске. Эта запись маски устанавливается автоматически, чтобы привести все записи в групповом классе к общему знаменателю. Кроме того, setfacl автоматически адаптирует существующие записи масок к измененным настройкам, если вы не деактивируете эту функцию с помощью -n . mask определяет максимальные действующие разрешения на доступ ко всем записям в групповом классе. Сюда входят именованный пользователь, именованная группа и группа-владелец. Биты разрешения класса группы, которые будут отображаться с помощью ls -dl mydir, теперь соответствуют записи маски.
drwxrwx--+ . смокинг проект3. мой каталог
Первый столбец вывода теперь содержит дополнительный +, указывающий, что для этого элемента существует расширенный ACL.
Редактируйте запись маски с помощью setfacl или chmod .
ls -dl mydir
getfacl mydir
После выполнения команды chmod для удаления разрешения на запись из битов класса группы выходных данных команды ls достаточно, чтобы увидеть, что биты маски должны были измениться соответствующим образом: разрешение на запись снова ограничено владельцем mydir . Вывод getfacl подтверждает это. Этот вывод включает комментарий для всех тех записей, где биты действующих разрешений не соответствуют исходным разрешениям, потому что они отфильтрованы в соответствии с записью маски. Конечно, исходные разрешения можно восстановить в любое время с помощью chmod :
ls -dl mydir
getfacl mydir
Каталог с ACL по умолчанию
Каталоги могут быть снабжены особым типом ACL — ACL по умолчанию. ACL по умолчанию определяет права доступа, которые наследуют все объекты в этом каталоге при их создании. ACL по умолчанию влияет как на подкаталоги, так и на файлы.
Влияние ACL по умолчанию
Существует два разных способа передачи разрешений списка ACL каталога по умолчанию для файлов и подкаталогов в нем:
<УЛ>Все системные вызовы, создающие объекты файловой системы, используют параметр режима, определяющий права доступа для вновь созданного объекта файловой системы:
<УЛ>
Применение ACL по умолчанию
В следующих трех примерах показаны основные операции для каталогов и списков управления доступом по умолчанию:
<УЛ><ПР> Добавьте ACL по умолчанию в существующий каталог mydir :
Опция -d команды setfacl предлагает setfacl выполнить следующие изменения (опция -m ) в ACL по умолчанию.
Внимательно посмотрите на результат этой команды:
getfacl возвращает как ACL доступа, так и ACL по умолчанию. Список ACL по умолчанию формируется из всех строк, начинающихся с default . Хотя вы просто выполнили команду setfacl с записью для группы djungle для ACL по умолчанию, setfacl автоматически скопировал все остальные записи из ACL доступа, чтобы создать действительный ACL по умолчанию. ACL по умолчанию не оказывают немедленного влияния на права доступа. Они вступают в игру только при создании объектов файловой системы. Эти новые объекты наследуют разрешения только из ACL по умолчанию их родительского каталога.
Как и ожидалось, только что созданный подкаталог mysubdir имеет разрешения из списка управления доступом по умолчанию родительского каталога. ACL доступа mysubdir является точным отражением ACL по умолчанию для mydir, так же как и ACL по умолчанию, который этот каталог будет передавать своим подчиненным объектам.
ls -l mydir/myfile
getfacl mydir/myfile
В этом примере важно: сенсорный режим переходит со значением 0666 , что означает, что новые файлы создаются с разрешениями на чтение и запись для всех классов пользователей, при условии, что в umask или в ACL по умолчанию не существует других ограничений (см. B) .
Если действует, это означает, что все права доступа, не содержащиеся в значении режима, удаляются из соответствующих записей ACL. Хотя никакие разрешения не были удалены из записи ACL класса группы, запись маски была изменена, чтобы скрыть разрешения, не установленные через режим.
Алгоритм проверки ACL
В следующем разделе представлена краткая информация об алгоритме проверки, применяемом ко всем процессам или приложениям, прежде чем им будет предоставлен доступ к объекту файловой системы, защищенному с помощью ACL. Как правило, записи ACL проверяются в следующей последовательности: владелец, именованный пользователь, группа-владелец или именованная группа и другие. Доступ обрабатывается в соответствии с записью, которая лучше всего подходит для процесса; разрешения не накапливаются.
Все становится сложнее, если процесс принадлежит более чем к одной группе и потенциально подходит для нескольких групповых записей. Запись выбирается случайным образом из подходящих записей с требуемыми разрешениями. Неважно, какая из записей инициирует окончательный результат «доступ предоставлен». Аналогичным образом, если ни одна из подходящих записей группы не содержит правильных разрешений, случайно выбранная запись вызывает окончательный результат «отказано в доступе».
Перспективы
Как описано в предыдущих разделах, списки управления доступом можно использовать для реализации очень сложных сценариев разрешений, отвечающих требованиям современных приложений. Традиционную концепцию разрешений и ACL можно разумно комбинировать. Однако некоторые важные приложения по-прежнему не поддерживают ACL. Кроме звездного архиватора, в настоящее время нет приложений для резервного копирования, гарантирующих полное сохранение ACL.
Основные файловые команды ( cp , mv , ls и т. д.) поддерживают списки управления доступом, но многие редакторы и файловые менеджеры (например, Konqueror) этого не делают. Например, при копировании файлов с помощью Konqueror ACL этих файлов теряются. При изменении файлов с помощью редактора ACL файлов иногда сохраняются, иногда нет, в зависимости от режима резервного копирования используемого редактора:
<УЛ>Поскольку (будем надеяться) со временем будет выпущено больше приложений с поддержкой ACL, системы Linux смогут в полной мере воспользоваться преимуществами этой функции.
Списки управления доступом (ACL) POSIX — это более подробные права доступа к файлам и каталогам. ACL состоит из записей, определяющих права доступа к связанному объекту. ACL можно настроить для каждого пользователя, для каждой группы или с помощью маски действующих прав.
Эти разрешения применяются к отдельному пользователю или группе и используются так же, как rwx в обычных разрешениях.
Объяснение rwx см. в разделе FilePermissions
Перед началом работы со списками контроля доступа файловая система должна быть смонтирована с включенными списками контроля доступа. Это можно сделать в /etc/fstab, чтобы изменения были постоянными.
0) Возможно, потребуется установить утилиты acl из репозиториев. В Server Edition это необходимо сделать, но в настольных редакциях acl устанавливается по умолчанию.
1) Добавьте опцию acl в раздел(ы), для которых вы хотите включить ACL, в /etc/fstab. Например:
Начиная с Ubuntu 14.04 и ext4 вышеуказанное не требуется, так как acl уже используется по умолчанию:
2) При необходимости перемонтируйте разделы, на которых были включены ACL, чтобы они вступили в силу. Например:
3) Убедитесь, что списки контроля доступа включены в разделе(ах):
Записи ACL состоят из пользователя (u), группы (g), другого (o) и маски действующих прав (m). Эффективная маска прав определяет наиболее ограничивающий уровень разрешений. setfacl устанавливает разрешения для данного файла или каталога. getfacl показывает разрешения для данного файла или каталога.
Можно определить значения по умолчанию для данного объекта.
Списки управления доступом можно применять к пользователям или группам, но управлять группами проще. Группы масштабируются лучше, чем постоянное добавление или удаление пользователей.
Список ACL
Утилита getfacl выводит список ACL для данного файла или каталога.
Для этого следующего ACL также установлены значения по умолчанию:
Добавление группы в ACL
Утилита setfacl используется для добавления групп blue и green в ACL для каталога /var/www.
Удаление группы из ACL
Опция -x удаляет группы или пользователей из заданного ACL. Ниже группа зеленого цвета удалена из каталога /var/www.
Перенос атрибутов ACL из файла спецификации
Перенос атрибутов ACL из файла спецификации выполняется в два этапа. В этом примере файл спецификации называется acl.
Сначала создайте файл, содержащий список управления доступом, который будет использоваться.
Затем прочитайте содержимое файла в setfacl, чтобы установить ACL для каталога /path/to/dir
Вывод из getfacl принимается при чтении из файлов с помощью -M.
Копирование ACL из одного файла или каталога в другой
При копировании ACL из dir1 в dir2 используется параметр -M. Выходные данные getfacl принимаются в качестве входных данных для setfacl при использовании -M.
-b очистить ACL, -n не пересчитывать действующую маску прав, - читать из stdin
Или это можно сделать так:
Копирование ACL в ACL по умолчанию
Как только списки управления доступом станут такими, какими они должны быть, их можно установить по умолчанию. Значения по умолчанию наследуются, поэтому новый каталог унаследует значения по умолчанию родительского каталога.
К спискам управления доступом Linux, или ACL, может потребоваться некоторое время, чтобы привыкнуть, но они бесценны для более точного управления разрешениями вашей файловой системы Linux.
Опубликовано: 6 февраля 2020 г. | Глен Ньюэлл
Фото Pixabay: Pexels
Одной из проблем администрирования Linux в современной бизнес-среде является ожидание того, что мы можем и должны управлять тем, кто имеет доступ к какой информации. Когда-то людей, которым требовался доступ к файловым системам Linux, можно было разделить на общие категории: через разрешения файловой системы Linux.
Обзор основ
Дополнительные ресурсы по Linux
Файловая система Linux дает нам три типа разрешений. Вот упрощенный обзор:
С этими разрешениями мы можем предоставить три (на самом деле пять, но мы доберемся до этого через минуту) типа доступа:
Эти уровни доступа часто достаточны во многих случаях. Скажем, у вас есть директория, в которой живут файлы из бухгалтерии. Вы можете установить следующие разрешения:
Пользователь службы учета (владелец пользователя) может читать и записывать в каталог, а члены группы учета (или группы владельцев) могут читать и записывать. Однако другие (пользователи, не работающие в бухгалтерии) могут видеть и выполнять то, что там находится, что некоторым может показаться плохой идеей.
Итак, мы можем изменить разрешения на это:
Примечание. Вы также можете использовать специальные разрешения для управления такими настройками, как, например, кто на самом деле владеет новыми файлами, созданными в этом каталоге, а также привязку, которая определяет, могут ли члены группы удалять файлы друг друга. Однако это выходит за рамки данного обсуждения.
Просмотр текущего ACL
Что делать, если у вас есть стажер по бухгалтерскому учету (Кенни), которому нужно иметь возможность читать определенные файлы (или даже только файлы, принадлежащие Фреду, его менеджеру)? Или, может быть, людям в отделе продаж также нужен доступ к файлам владельца бухгалтерии, чтобы создавать счета для команды Фреда, чтобы выставлять счета клиентам, но вы не хотите, чтобы отдел продаж видел другие отчеты, которые создает команда Фреда. Эта ситуация может быть сложной, поскольку при обычных разрешениях у каждого файла и каталога может быть только один пользователь и владелец группы одновременно. Списки управления доступом (ACL) Linux предназначены для разрешения таких ситуаций.
Списки управления доступом позволяют нам применять более конкретный набор разрешений к файлу или каталогу без (обязательно) изменения основного владельца и разрешений. Они позволяют нам «прикрепить» доступ для других пользователей или групп.
Мы можем просмотреть текущий ACL с помощью команды getfacl:
Мы видим, что прямо сейчас в этом каталоге нет списков ACL, потому что перечислены только разрешения для пользователя, группы и других. В данном случае этого следовало ожидать, потому что я только что создал этот каталог в лаборатории и не делал ничего, кроме назначения права собственности. Итак, начнем с добавления ACL по умолчанию:
Настройка ACL
Синтаксис для настройки ACL выглядит следующим образом:
Действием будет -m (изменить) или -x (удалить), а спецификацией будет пользователь или группа, за которыми следуют разрешения, которые мы хотим установить. В этом случае мы будем использовать опцию -d (по умолчанию). Итак, чтобы установить ACL по умолчанию для этого каталога, мы должны выполнить:
После чего мы теперь можем видеть информацию ACL по умолчанию для этого каталога:
Что, если Фред создаст файл в этом каталоге?
Что произойдет, если Кенни попытается создать файл? Вы можете догадаться, что, поскольку Кенни не входит в бухгалтерскую группу, у него не будет разрешения. Но мы хотим, чтобы у Кенни был хороший опыт работы с нами, поэтому мы должны дать ему возможность видеть, какие файлы находятся в каталоге учета, и мы хотим, чтобы он мог создавать новые файлы:
Пока все хорошо. Но что, если мы не хотим, чтобы этот пользователь создавал файлы в каталоге account? Вместо этого мы хотим, чтобы он только читал файлы там, и он мог создавать новые файлы в своей собственной папке.
Мы можем настроить доступ Кенни к папке учета следующим образом:
Вы создали папку в группе учетных записей, которой владеет пользователь kenny . Теперь он может видеть папку учета, но создавать файлы только в своей папке:
Обратите внимание: поскольку папка принадлежит группе учетных записей, любой член этой группы может помещать туда файлы. Поскольку мы имеем дело со стажером, этот фактор, вероятно, в порядке вещей. Однако что, если мы повысим Кенни до главного аудитора и захотим сохранить его работу в секрете от Фреда?
Что, если мы не хотим, чтобы никто не видел, над чем работает Кенни?
Примечание. Если мы хотим установить список контроля доступа для группы, нам нужно указать это, поставив g: перед названием группы. Для пользователей просто измените g на u , но setfacl будет считать, что мы говорим о пользователе, если вы ничего не поместите в это место.
Нам по-прежнему нужно удалить базовые разрешения для владельца группы, чтобы остальные сотрудники бухгалтерии не могли просматривать отчеты Кенни:
Теперь мы можем управлять тем, кто еще может видеть или писать в папку Кенни, не меняя владельца. Давайте предоставим генеральному директору (Лизе, которая не является членом бухгалтерской группы и не будет иметь доступа к остальной части папки) доступ к материалам Кенни:
Еще раз обратите внимание, что разрешения владельца группы остаются широко открытыми, но группа учета (которая по-прежнему является владельцем) больше не имеет доступа к этой папке. Итак, кому он принадлежит?
Эта часть сложная. Полезно знать, что мы можем лишить владельца разрешений, не меняя владельца, но вы можете подумать, нужен ли вам такой результат.
Заключение
Итак, это основы. ACL могут сбивать с толку, поэтому я рекомендую вам внимательно прочитать справочные страницы для setfacl и getfacl. Есть много других интересных и полезных вещей, которые вы можете сделать с помощью этих инструментов, но, надеюсь, теперь вы понимаете достаточно, чтобы приступить к работе.
[ Хотите попробовать Red Hat Enterprise Linux? Скачайте сейчас бесплатно. ]
Как системный администратор в Linux, вам не потребуется много времени, чтобы понять, что разрешения, управляемые только с использованием файлового режима, становятся очень ограничивающими. Режим файла позволяет одному пользователю, одной группе и всем остальным, вот и все.Многие системы Linux являются однопользовательскими системами, действующими как сервисное устройство, поэтому все не так уж плохо, однако, если вы используете систему как некую форму общего сервера или файлового сервера, вероятно, вам потребуется расширить режим с использованием списков контроля доступа POSIX или списков контроля доступа.
Поддержка списков контроля доступа POSIX в Linux за последние годы расширилась, и в настоящее время большинство файловых систем и ядра поддерживают их.
Из предыдущего рисунка видно, что при проверке конфигурации ядра мы видим поддержку ACL.
У нас есть две команды: getfacl для чтения ACL и setfacl для управления ACL. Мы можем использовать ACL для лучшей защиты нашей системы. Мы можем удалить права, предоставленные другим, и обеспечить, чтобы новые файлы имели разрешения, предоставленные пользователю или группам, которым они нужны.
Защита корневого документа веб-сервера с помощью ACL
В этом примере мы рассмотрим установку веб-сервера Apache в CentOS и обеспечение правильной защиты файла.
Установите Apache
Разрешения по умолчанию являются слабыми для DocumentRoot /var/www/html. Веб-сервер использует разрешения, предоставленные другим пользователям:
Мы можем изменить владельца и разрешения, чтобы усилить безопасность. Мы также добавляем *липкий бит* в каталог, чтобы файлы могли быть удалены только их владельцем.
На данном этапе веб-сервер не имеет доступа к веб-контенту.
Добавление ACL
Нам необходимо убедиться, что каталог доступен для веб-сервера. Мы можем сделать это через группу или пользователя, связанного с сервером. Добавление группы в ACL по умолчанию и ACL каталога.
ПРИМЕЧАНИЕ. *Закрепляемый бит* или любые специальные разрешения отображаются в разделе *флаги* в комментариях. Мы очень быстро настроили ACL, чтобы обеспечить более безопасный доступ к DocumentRoot. Мы удалили разрешения от других и обеспечим, чтобы новые файлы имели разрешения, назначенные группе веб-сервера *apache* в системах CentOS.
Списки ACL POSIX (списки контроля доступа) можно использовать в качестве расширения традиционной концепции разрешений для объектов файловой системы. С помощью ACL разрешения могут быть определены более гибко, чем с традиционной концепцией разрешений.
Термин POSIX ACL предполагает, что это настоящий стандарт POSIX (интерфейс переносимой операционной системы). Соответствующие проекты стандартов POSIX 1003.1e и POSIX 1003.2c были отозваны по нескольким причинам. Тем не менее, списки ACL (находящиеся во многих системах, принадлежащих к семейству UNIX) основаны на этих проектах, и реализация списков ACL файловой системы (как описано в этой главе) также следует этим двум стандартам.
Подробную информацию о традиционных правах доступа к файлам можно найти на информационной странице GNU Coreutils, узел Разрешения на доступ к файлам ( info coreutils "Разрешения на доступ к файлам" ). Более продвинутые функции — setuid, setgid и sticky bit.
В некоторых ситуациях права доступа могут быть слишком строгими. Поэтому в Linux есть дополнительные настройки, которые позволяют временно изменить текущий идентификатор пользователя и группы для определенного действия. Например, программе passwd обычно требуются права суперпользователя для доступа к /etc/passwd. Этот файл содержит некоторую важную информацию, такую как домашние каталоги пользователей и идентификаторы пользователей и групп. Таким образом, обычный пользователь не сможет изменить пароль, потому что было бы слишком опасно предоставлять всем пользователям прямой доступ к этому файлу. Возможным решением этой проблемы является механизм setuid. setuid (установить идентификатор пользователя) — это специальный атрибут файла, который указывает системе выполнять программы, помеченные соответствующим образом под определенным идентификатором пользователя. Рассмотрим команду passwd:
Вы можете видеть символы s, которые означают, что бит setuid установлен для разрешения пользователя. С помощью бита setuid все пользователи, запускающие команду passwd, выполняют ее от имени пользователя root .
Бит setuid применяется к пользователям. Однако для групп также существует эквивалентное свойство: бит setgid. Программа, для которой был установлен этот бит, запускается под идентификатором группы, под которым она была сохранена, независимо от того, какой пользователь запускает ее. Поэтому в каталоге с битом setgid все вновь создаваемые файлы и подкаталоги назначаются группе, к которой принадлежит каталог. Рассмотрим следующий пример каталога:
Вы можете видеть символы s, которые означают, что бит setgid установлен для группового разрешения. Владелец каталога и члены группового архива могут получить доступ к этому каталогу. Пользователи, не являющиеся членами этой группы, «сопоставляются» с соответствующей группой. Эффективным групповым идентификатором всех записанных файлов будет архив. Например, программа резервного копирования, работающая с архивом идентификатора группы, может получить доступ к этому каталогу даже без привилегий root.
Есть также закрепляющий бит .Имеет значение, принадлежит ли он исполняемой программе или каталогу. Если он принадлежит программе, файл, помеченный таким образом, загружается в оперативную память, чтобы избежать необходимости получать его с жесткого диска каждый раз, когда он используется. Этот атрибут используется редко, потому что современные жесткие диски достаточно быстрые. Если этот бит назначен каталогу, он запрещает пользователям удалять файлы друг друга. Типичные примеры включают каталоги /tmp и /var/tmp:
Традиционно для каждого файлового объекта в системе Linux определяются три набора разрешений. Эти наборы включают права на чтение (r), запись (w) и выполнение (x) для каждого из трех типов пользователей — владельца файла, группы и других пользователей. В дополнение к этому можно установить set user id , set group id и sticky bit. Эта концепция бережливого производства полностью подходит для большинства практических случаев. Однако для более сложных сценариев или расширенных приложений системным администраторам раньше приходилось использовать ряд обходных путей, чтобы обойти ограничения традиционной концепции разрешений.
Списки управления доступом можно использовать как расширение традиционной концепции прав доступа к файлам. Они позволяют назначать разрешения отдельным пользователям или группам, даже если они не соответствуют первоначальному владельцу или группе-владельцу. Списки управления доступом являются функцией ядра Linux и в настоящее время поддерживаются ReiserFS, Ext2, Ext3, JFS и XFS. С помощью ACL можно реализовать сложные сценарии без реализации сложных моделей разрешений на уровне приложения.
Преимущества списков ACL очевидны, если вы хотите заменить сервер Windows сервером Linux. Некоторые из подключенных рабочих станций могут продолжать работать под управлением Windows даже после миграции. Система Linux предлагает файловые службы и службы печати для клиентов Windows с Samba. Благодаря тому, что Samba поддерживает списки контроля доступа, права доступа пользователей можно настраивать как на сервере Linux, так и в Windows с графическим пользовательским интерфейсом (только Windows NT и более поздние версии). С помощью winbindd , входящего в состав пакета samba, можно даже назначать разрешения пользователям, существующим только в домене Windows, без какой-либо учетной записи на сервере Linux.
Традиционная концепция разрешений POSIX использует три класса пользователей для назначения разрешений в файловой системе: владелец, группа-владелец и другие пользователи. Для каждого класса пользователей можно установить три бита разрешений, дающих разрешение на чтение (r), запись (w) и выполнение (x).
Разрешения пользователей и групп на доступ ко всем типам объектов файловой системы (файлам и каталогам) определяются с помощью списков ACL.
Списки управления доступом по умолчанию можно применять только к каталогам. Они определяют разрешения, которые объект файловой системы наследует от своего родительского каталога при создании.
Каждый ACL состоит из набора записей ACL. Запись ACL содержит тип, квалификатор пользователя или группы, к которым относится запись, и набор разрешений. Для некоторых типов записей квалификатор группы или пользователей не определен.
Таблица 10.1, «Типы записей ACL», суммирует шесть возможных типов записей ACL, каждый из которых определяет разрешения для пользователя или группы пользователей. Запись owner определяет разрешения пользователя, владеющего файлом или каталогом. Запись группа-владелец определяет разрешения группы-владельца файла. Суперпользователь может изменить владельца или группу владельцев с помощью chown или chgrp , и в этом случае записи владельца и группы владельцев относятся к новому владельцу и группе владельцев. Каждая запись имя пользователя определяет разрешения пользователя, указанного в поле квалификатора записи. Каждая запись именованной группы определяет разрешения группы, указанной в поле квалификатора записи. Только записи именованного пользователя и именованной группы имеют непустое поле квалификатора. Запись other определяет права всех остальных пользователей.
Запись mask дополнительно ограничивает разрешения, предоставляемые именованным пользователем, именованной группой и записями группы-владельца, определяя, какие из разрешений в этих записях действуют, а какие маскируются. Если разрешения существуют в одной из упомянутых записей, а также в маске, они действуют. Разрешения, содержащиеся только в маске или только в фактической записи, не действуют, т. е. разрешения не предоставляются. Все разрешения, определенные в записях владельца и группы-владельца, действуют всегда. Пример в таблице 10.2 «Маскировка прав доступа» демонстрирует этот механизм.
Существует два основных класса списков ACL: минимальный ACL содержит только записи для типов владельца, группы-владельца и других, которые соответствуют обычным битам разрешений для файлов и каталогов. расширенный ACL выходит за рамки этого. Он должен содержать запись маски и может содержать несколько записей типа именованного пользователя и именованной группы.
Читайте также: