ACL

Access Control Lists

В этой статье попробуем описать работу с ACL применительно к файлам в стандартных файловых системах (ext и т.п.), укажем основные нюансы при переходе от стандартных прав к расширенным и приведем конкретные примеры практического использования ACL.

Зачем оно нужно

Как известно "из коробки" нам доступен стандартный набор прав на файлы: "пользователь - группа - остальные" ("user-group-others") плюс такие "бонусы" как SUID, SGID и Sticky биты. Подробнее об этом написано ТУТ (где ???). Возможности, предоставляемые стандартным набором прав, достаточно велики, чтобы потребовалось нечто большее, но бывают ситуации, когда нужно дать доступ отдельным пользователям (группам) на файлы, собственниками которых они не являются, либо, наоборот, сделать явный запрет не для всех.

Проверка на возможность работы с ACL

Вообще говоря, ACL должны поддерживаться файловой системой (раз) и сама файловая система должна быть смонтирована с поддержкой ACL (иначе изменять ACL правила будет невозможно, но имеющиеся все же применяться будут). Проверим это командой:

 # mount
 ...
 /dev/sda on / type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
 ...

Кроме того нам необходим нехитрый инструментарий, который в ALTLinux содержится в пакете acl (NB: по умолчанию в p6 simple, например, не установлен):

 # apt-get install acl

Так мы получим две команды: setfacl и getfacl

Расширенные права

Если рассмотреть файл с точки зрения расширенных прав, то теперь мы оперируем следующим:

• владелец
• другие отдельные пользователи (поименно)
• группа владельца
• отдельные группы (тоже списком)
• остальные
• mask (важное дополнение)

И помимо этого, только для директорий, есть те же самые "структурные единицы", права которых будут применяться по-умолчанию для всех объектов, создаваемых в этой директории.

На каждого пользователя/группы и остальных действуют права по принципу rwx, аналогично стандартным (для файла - читать, изменять, выполнять; для директории - листинг, изменение, доступ к содержимому).

Однако, те права, которые назначены группе пользователя, другим группам, а также пользователям, отличных от владельца, еще и обрабатываются параметром mask. Таким образом, эффективное значение прав доступа для указанных групп (нетронутыми остаются только сам владелец и "остальные") является логическое "И" начального значения и маски. Но если раньше маски у файла не было (не путать с параметром umask - он здесь ни при чем), то как он назначается. Дело в том, что, когда файлу дают дополнительные права, то происходит "преобразование" исходных прав до полного комплекта прав ACL. Пример:

$ touch file
$ ls -l file
-rw-r--r-- 1 guest guest 0 Янв 18 14:02 file
$ getfacl file
# file: file
# owner: guest
# group: guest
user::rw-
group::r--
other::r--

$ setfacl -n -m u:mister:rw- file   #Даем пользователю mister права на чтение и запись файла file
$ ls -l file
-rw-r--r--+ 1 guest guest 0 Янв 18 14:02 file
$ getfacl file
# file: file
# owner: guest
# group: guest
user::rw-
user:mister:rw-    #effective:r--
group::r--
mask::r--
other::r--

Первое важное замечание: в выводе ls после списка прав появился знак "плюс", что указывает на неполноту информации - следует использовать getfacl. А в этом случае мы видим две новые строчки: mask::r-- и user:mister:rw- #effective:r-- Результат применения маски на те права, что мы дали mister'у очевиден, но откуда взялась сама маска ? Ответ: при расширении стандартных прав до полных ACL маска становится такой же, как права группы до модификации. В нашем случае, r--. Значение group также осталось неизменным, но это не обязательно, так как если файл создается в директории, на которую назначены права по-умолчанию, то применяться к файлу будут именно они. И еще одно правило: при работе с расширенными правами параметр umask силы не имеет, но mode действует: файлы (в отличие от директорий) создаются без права на исполнение.