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--

Проанализируем вывод:

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

Замечу, что параметр mask создается в том случае, когда задается хотя бы одна именованная запись (группа или пользователь). Соответственно, своя маска для прав файла и дефолтная - для директорий. Если же просто добавить неименованные default записи к стандартному файлу, mask тоже не создается. Воспользуемся этим:

$ mkdir dir
$ setfacl -m d:o:rwx dir
$ ls -ld dir
drwxr-xr-x+ 2 guest guest 4096 Янв 18 16:19 dir
$ getfacl dir
# file: dir
# owner: guest
# group: guest
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::rwx

$touch dir/file
$ls -l dir/file
-rw-r--rw- 1 guest guest 0 Янв 18 16:21 dir/file
$ mkdir dir/dir2
$ ls -ld dir/dir2
drwxr-xrwx+ 2 guest guest 4096 Янв 18 16:21 dir/dir2
$ getfacl dir/dir2
# file: dir/dir2
# owner: guest
# group: guest
user::rwx
group::r-x
other::rwx
default:user::rwx
default:group::r-x
default:other::rwx

Теперь мы видим: 1. Маска нигде не создается. И ограничений от нее нет. (Иначе group превратилась бы в mask и "испортила" права.) 2. Файлы создаются в "ACL-ной" директории обычные, а вот новые директории перенимают default права. 3. Файлам не дается право запуска (mode ограничение).

Если же мы добавим права конкретного пользователя к директории:

$ setfacl -nm u:mister:rwx,d:u:mister:rwx dir
$ getfacl dir
# file: dir
# owner: guest
# group: guest
user::rwx
user:mister:rwx			#effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:mister:rwx		#effective:r-x
default:group::r-x
default:mask::r-x
default:other::rwx

$ touch dir/file2
$ getfacl dir/file2
# file: dir/file2
# owner: guest
# group: guest
user::rw-
user:mister:rwx			#effective:r--
group::r-x			#effective:r--
mask::r--
other::rw-

$ mkdir dir/dir3
$ getfacl dir/dir3
# file: dir/dir3
# owner: guest
# group: guest
user::rwx
user:mister:rwx			#effective:r-x
group::r-x
mask::r-x
other::rwx
default:user::rwx
default:user:mister:rwx		#effective:r-x
default:group::r-x
default:mask::r-x
default:other::rwx

То тут же получим весь букет ограничений от маски для измененного файла/директории (но не вложенных !)