В некоторых ситуациях привилегии доступа могут быть слишком строгими. Поэтому в Linux существуют дополнительные настройки, позволяющие для определенного действия временно сменить идентификатор текущего пользователя или группы. Например, программа passwd обычно требует привилегий суперпользователя для доступа к файлу /etc/passwd. Этот файл содержит важную информацию, такую как домашние каталоги пользователей, идентификаторы пользователей и групп. Таким образом обычный пользователь не сможет изменить passwd, потому что предоставлять всем пользователям прямой доступ к этому файлу слишком опасно. Возможным решением этой проблемы является механизм setuid. setuid (set user ID - установка идентификатора пользователя) это специальный файловый аттрибут, который сообщает системе, что программу нужно выполнять используя определенный идентификатор пользователя. Рассмотрим команду passwd:

-rwsr-xr-x  1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd

Вы видите s, что указывает на установленный бит setuid для привилегий пользователя. Согласно ему, все пользователи, запускающие команду passwd, выполнят ее от пользователя root.

Бит setuid применяется к пользователям. Однако существует аналогичное свойство для групп: бит setgid. Если этот бит установлен для программы, то программа будет использовать при работе идентификатор собственной группы, вне зависимости от того, какой пользователь ее запустил. В директории с установленным битом setgid, все вновь созданные поддиректории и файлы будут принадлежать к той же группе, к которой принадлежит директория. Рассмотрим следующую директорию:

drwxrws--- 2 tux archive 48 Nov 19 17:12  backup

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

Существует также sticky bit. Его поведение отличается для файлов и директорий. Если он установлен для исполняемого файла, то соответствующая программа не будет выгружаться из оперативной памяти, чтобы избежать повторной загрузки с жесткого диска. Поскольку современные жесткие диски достаточно производительны, используется это редко. Если этот бит установлен для директории, пользователи не смогут удалять из нее чужие файлы. Типичными примерами являются директории /tmp и /var/tmp:

drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp

Рисунок 9.1, «Минимальный ACL: Сравнение записей ACL с битами доступа» и Рисунок 9.2, «Расширенный ACL: Сравнение записей ACL с битами доступа» соответствуют минимальному и расширенному ACL. На рисунках изображены три блока: левый показывает тип спецификации записей ACL, центральный отображает пример ACL, и правый блок соответствует битам доступа традиционной концепции привилегий (отображаемым, например, командой ls -l). В обоих случаях привилегии класса владелец отображаются на запись ACL «владелец». Привилегии класса другие отображаются на соответствующую запись ACL. Однако отображение прав доступа класса группа отличается для каждого из случаев.

Рисунок 9.1. Минимальный ACL: Сравнение записей ACL с битами доступа¶

В случае минимального ACL — без маски — права доступа группы отражаются на запись ACL группа-владелец, как показывает Рисунок 9.1, «Минимальный ACL: Сравнение записей ACL с битами доступа». В случае расширенного ACL— с маской — права доступа группы отображаются на маску, Рисунок 9.2, «Расширенный ACL: Сравнение записей ACL с битами доступа».

Рисунок 9.2. Расширенный ACL: Сравнение записей ACL с битами доступа¶

Это отображение используется для упрощения взаимодействия с приложениями, избавляя от небходимости поддержки ACL приложением. Привилегии доступа, назначенные посредством битов доступа, задают верхний предел для всех «тонких настроек», сделанных при помощи ACL. Изменение битов доступа отражается на ACL и наоборот.

Вы можете получить доступ к ACL с помощью команд getfacl и setfacl. Использование этих команд показано в следующем примере.

Перед созданием директории используйте команду umask, чтобы задать биты доступа маскируемые при создании файлового объекта. Команда umask 027 устанавливает привилегии по умолчанию следующим образом: владелец получает полный доступ (0), группе запрещен доступ на запись (2), доступ остальным пользователям закрыт (7). В действительности umask маскирует соответствующие биты доступа или сбрасывает их. Подробности можно узнать на man странице umask.

mkdir mydir создает директорию mydir с привилегиями, установленными командой umask. С помощью ls -dl mydir можно определить правильность установки привилегий. Для данного примера вывод будет следующим:

drwxr-x--- ... tux project3 ... mydir

Используя getfacl mydir, проверьте исходное состояние ACL. Будет отображена следующая информация:

# file: mydir 
# owner: tux 
# group: project3 
user::rwx 
group::r-x 
other::---

Первые три строки вывода отображают имя, владельца и группу-владельца директории. Следующие три строки содержат три записи ACL: «владелец», «группа-владелец» и «другие». Фактически мы имеет дело с минимальным ACL и команда getfacl не дает дополнительной информации по сравнению с командой ls.

Измените ACL, разрешив доступ на чтение, запись и выполнение пользователю geeko и группе mascots командой:

setfacl -m user:geeko:rwx,group:mascots:rwx mydir

Опция -m указывает setfacl изменить существующий ACL. Следующий за ней аргумент определяет записи ACL, которые будут изменены (можно указать несколько записей, разделяя из запятыми). Последняя часть определяет имя директории, к которой будут применены эти изменения. Используйте команду getfacl, чтобы узнать полученные ACL.

# file: mydir 
# owner: tux 
# group: project3 
user::rwx 
user:geeko:rwx 
group::r-x
group:mascots:rwx 
mask::rwx 
other::---

В дополнение к записям, созданным для пользователя geeko и группы mascots, была добавлена запись с маской. Эта запись была создана автоматически, таким образом, что все заданные права доступа будут применены. setfacl автоматически адаптирует существующие записи с масками к изменяемым битам. Это поведение можно изменить используя опцию -n. Маска определяет максимальные эффективные привилегии для класса «группа», включая именованного пользователя, именованную группу и группу-владельца. Биты доступа класса «группа», отображаемые командой ls, -dl mydir теперь соответствуют записи маска.

drwxrwx---+ ... tux project3 ... mydir

Первый столбец вывода теперь содержит дополнительно знак +, указывая на существование расширенных ACL для этого элемента.

Согласно выводу команды ls, маска включает в себя доступ на запись. Традиционно эти биты означали бы, что группа-владелец (project3) также имеет право на запись в директорию mydir. Однако эффективные права доступа соответствуют сочетанию прав заданных для группы-владельца и маски — r-x в нашем примере (Таблица 9.2, «Маскировка привилегий доступа»). Поэтому в отношении эффективных привилегий группы-владельца, даже после добавления дополнительных записей ACL, ничего не изменилось.

Измените значение маски с помощью команд setfacl или chmod. Например используйте chmod g-w mydir. ls -dl mydir покажет:

drwxr-x---+ ... tux project3 ... mydir

getfacl mydir даст следующий вывод:

# file: mydir 
# owner: tux 
# group: project3 
user::rwx 
user:geeko:rwx          # effective: r-x
group::r-x 
group:mascots:rwx       # effective: r-x 
mask::r-x 
other::---

После сброса бита доступа на запись для группы командой chmod, вывода команды ls достаточно, чтобы увидеть, что биты маски изменились: доступ на запись снова есть только у владельца mydir. Вывод getfacl подтверждает это. Он включает в себя комментарий для всех записей, в которых биты доступа не соответствуют реальным привилегиям из-за применения маски. Оригинальные права могут быть восстановлены в любое время командой chmod g+w mydir.

Директории могут иметь ACL по умолчанию, которые являются специальной разновидностью ACL, определяющей права доступа, наследуемые объектами в этой директории при их создании. ACL по умолчанию влияет на поддиректории и файлы.

Алгоритм проверки применяется перед тем, как любому процессу или приложению будет предоставлен доступ к защищенному ACL объекту файловой системы. Основное правило проверки заключается в том, что записи ACL проверяются в следующем порядке: владелец, именованный пользователь, группа-владелец или именованная группа, другие пользователи. Доступ предоставляется в соответствии с записью, которая более подходит процессу. Привилегии не накапливаются.

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