user:joe:rwx

group::r-x

mask::rwx

other::---

В ACL были добавлены две дополнительные записи: одна для пользователя Joe, другая – запись-маска. Запись-маска автоматически создается, когда это необходимо. Ее разрешения являются объединением разрешений всех записей класса групп, и, таким образом, она не маскирует никакие разрешения.

Теперь запись-маска будет определять разрешения для класса групп. Вывод команды ls изменится и будет выглядеть так, как это показано ниже.

$ ls -dl dir

drwxrwx---+ . agruen suse . dir

Дополнительный символ “+” добавляется ко всем файлам, для которых определен расширенный ACL. На первый взгляд этот дополнительный символ кажется вовсе ненужным, но на самом деле POSIX.1 назначает этому символу необязательный флаг альтернативного метода доступа, который по-умолчанию устанавливается пустым, если не используются никаких альтернативных методов доступа. Таким образом, этот символ указывает на то, что если определен альтернативный метод доступа, то в процессе доступа к такому файлу будут использоваться именно он.

Разрешения класса групп содержат разрешение на запись. Традиционно такие биты файловых разрешений показывают возможность записи для группы-владельца. В случае, если определен ACL, эффективными разрешениями для группы-владельца будет пересечение разрешений группы владельца и записи-маски. Эффективные разрешения для группы-владельца в данном примере по прежнему “r-x”, т.е после создания дополнительных ACE командой setfacl(1) они не изменились.

Разрешения класса групп могут быть изменены при помощи команд setfacl(1) или chmod(1). Если не определена запись-маска, chmod(1) изменит разрешения записи группы-владельца традиционно. В следующем примере командой chmod(1) запретим доступ на запись для класса групп и посмотрим, что изменилось.

$ chmod g-w dir

$ ls -dl dir

drwxr-x---+ . agruen suse . dir

$ getfacl --omit-header dir

user::rwx

user:joe:rwx #effective:r-x

group::r-x

mask::r-x

other::---

Как показано выше, если ACE содержит разрешения, которые превышают разрешения записи-маски, команда getfacl добавляет комментарий к этой ACE, который показывает эффективный набор разрешений, гарантированный этой ACE. Если бы ACE группы-владельца содержала бы разрешения на запись, то к ней был бы добавлен такой же комментарий. Посмотрим теперь, что изменится, если вернуть разрешения на запись для класса групп.

$ chmod g+w dir

$ ls -dl dir

drwxrwx---+ . agruen suse . dir

$ getfacl --omit-header dir

user::rwx

user:joe:rwx

group::r-x

mask::rwx

other::---

После добавления разрешения на запись для класса групп, ACL вновь определяет те же разрешения на доступ, как и до запрещения записи для класса групп. Команда chmod(1) производит неразрушительный эффект на ACL. Это особенность является чрезвычайно важной для POSIX.1e ACL.

3.2.3 Пример ACL по-умолчанию

В следующем примере добавим ACL по-умолчанию к катологу и посмотрим, что изменилось в выводе команды getfacl.

$ setfacl -d -m group:toolies:r-x dir

$ getfacl --omit-header dir

user::rwx

user:joe:rwx

group::r-x

mask::rwx

other::---

default:user::rwx

default:group::r-x

default:group:toolies:r-x

default:mask::r-x

default:other::---

Текстовое представление ACL по-умолчанию выгладит также, как и ACL доступа, за исключением того, что перед ACE по-умолчанию добавляется префикс “default:”. Этот формат вывода является расширением POSIX.1e, которое применяется в Solaris и Linux. Строгое соответствие POSIX.2c проявляется только для ACL доступа. Посмотреть ACL по-умолчанию можно используя опцию –d команды getfacl(1).

В данном примере была указана ACE для группы toolies в команде setfacl(1). Остальные ACE, необходимые для полноценного ACL, автоматически скопировались из ACL доступа. Это специфическая особенность Linux; в других операционных системах может потребоваться конкретное указание всех необходимых записей.

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

Подкаталог наследует ACL как это показано ниже. Если не указано иначе, команда mkdir использует значение 0777 (0rwxrwxrwx) в качестве параметра режима доступа для системного вызова на создание нового каталога. В итоге и ACL доступа, и ACL по-умолчанию нового подкаталога будут содержать одинаковые ACE.

$ mkdir dir/subdir

$ getfacl --omit-header dir/subdir

user::rwx

group::r-x

group:toolies:r-x

mask::r-x

other::---

default:user::rwx

default:group::r-x

default:group:toolies:r-x

default:mask::r-x

default:other::---

Файлы, создаваемые внутри каталога, наследуют его разрешения так, как это показано ниже. Команда touch использует значение 0666 (0rw-rw-rw-) в качестве параметра режима доступа для системного вызова на создание нового файла.

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

$ touch dir/file

$ ls -l dir/file

-rw-r-----+ . agruen suse . dir/file

$ getfacl --omit-header dir/file

user::rw-

group::r-x #effective:r--

group:toolies:r-x #effective:r--

mask::r--

other::---

Никакие разрешения не были удалены из ACE класса групп. Вместо этого они были замаскированы и, таким образом, стали неэффективными. Это гарантирует, что традиционные инструменты, такие как компиляторы, будут правильно взаимодействовать с ACL. Они могут создавать файлы с ограниченными разрешениями и позже добавлять к ним права на выполнение. Механизм маски позволяет гарантировать необходимые права на доступ только для правильных пользователей и групп.

3.2.4 Расширенные атрибуты

В этом параграфе буте детально рассмотрена реализация ACL в Linux.

ACL представляют собой информационные блоки переменной длины, ассоциированные с объектами файловой системы. В каждой операционной существуют определенные правила хранения ACL для конкретной файловой системы, как например в Solaris для файловой системы UFS [13]. Каждый узел inode в файловой системе UFS имеет поле i_shadow. Если узел inode имеет ACL, то это поле указывает на теневой inode. В файловой системе теневые inode используются как обычные файлы. Каждый теневой inode хранит ACL в своем блоке данных. Несколько файлов с одним и тем же ACL могут ссылаться на один и тот же теневой inode.

Так как многие системные и пользовательские расширения в дополнение к ACL выигрывают от возможности ассоциировать блоки данных с файлами, Linux и большинство других UNIX-подобных операционных систем реализуют более общий механизм расширенных атрибутов (Extended Attributes, EAs). В таких системах ACL реализовывается в виде EAs.