Читаем Linux API. Исчерпывающее руководство полностью

Приведем еще один пример на основе рис. 17.1. Допустим, у нас есть процесс с GID 102, причем среди идентификаторов дополнительных групп есть также идентификатор 103. Для такого процесса вызовы access(file, R_OK) и access(file, W_OK) завершились бы успешно, поскольку они соответствовали бы записи ACL_GROUP для идентификаторов 102 и 103. С другой стороны, системный вызов access(file, R_OK | W_OK) привел бы к ошибке, так как здесь нет совпадающей записи ACL_GROUP, которая предоставляла бы права доступа на чтение и запись одновременно.

17.3. Длинная и краткая текстовые формы списков контроля доступа

При манипулировании ACL-списками с помощью команд setfacl и getfacl (мы опишем их очень скоро) или некоторых библиотечных функций указывают текстовые представления записей ACL-списка. Для таких текстовых представлений допускаются два формата.

• ACL-список в длинной текстовой форме содержит по одной записи ACL на строку и может также включать комментарии, которые начинаются с символа # и продолжаются до конца строки. Команда getfacl выводит ACL-списки в длинной текстовой форме. Для команды setfacl с параметром — M acl-file, берущим ACL-спецификацию из файла, необходимо, чтобы эта спецификация была представлена в длинной текстовой форме.

• ACL-списки в краткой текстовой форме состоят из последовательности ACL-записей, разделенных запятыми.

В обеих формах каждая запись состоит из трех частей, разделенных двоеточиями:

tag-type: [tag-qualifier]: permissions

Часть tag-type содержит одно из значений, показанных в первом столбце табл. 17.1. Далее может следовать необязательная часть tag-qualifier, которая идентифицирует пользователя или группу по имени или числовому ID. Эта часть присутствует только для записей ACL_USER и ACL_GROUP. Ниже приведены все краткие текстовые формы ACL-списков, соответствующие традиционной маске прав доступа 0650:

u::rw-,g::r-x,o::-

u::rw,g::rx,o::-

user::rw,group::rx,other::-

В следующей краткой текстовой форме ACL-списка присутствуют два имени пользователей, имя группы и запись маски:

u::rw,u: paulh: rw,u: annabel: rw,g::r,g: teach: rw,m::rwx,o::-

Таблица 17.1. Расшифровка текстовых форм записи ACL-списка

Текстовые формы тега — Есть ли тег-спецификатор? — Соответствующий тип тега — Запись для…

u, user — Нет — ACL_USER_OBJ — Владельца файла (пользователя)

u, user — Да — ACL_USER — Указанного пользователя

g, group — Нет — ACL_GROUP_OBJ — Группы файла

g, group — Да — ACL_GROUP — Указанной группы

m, mask — Нет — ACL_MASK — Маски класса группы

o, other — Нет — ACL_OTHER — Остальных пользователей

17.4. Запись ACL_MASK и класс группы для ACL-списка

Если ACL-список содержит запись ACL_USER или ACL_GROUP, то должен включать запись ACL_MASK. Если же не содержит этих двух записей, то запись ACL_MASK является необязательной.

Запись ACL_MASK действует подобно верхней границе прав доступа, предоставляемых записями ACL-списка в так называемом классе группы — наборе всех записей ACL_USER, ACL_GROUP и ACL_GROUP_OBJ в списке ACL.

Цель записи ACL_MASK — обеспечить согласованное поведение при запуске приложений, которые не используют ACL-списки. В качестве примера, демонстрирующего необходимость записи с маской, предположим, что ACL-список файла содержит следующие записи:

user::rwx # ACL_USER_OBJ

user: paulh: r-x # ACL_USER

group::r-x # ACL_GROUP_OBJ

group: teach:-x # ACL_GROUP

other::-x # ACL_OTHER

Предположим теперь, что программа выполняет следующий системный вызов chmod():

chmod(pathname, 0700); /* Установить права доступа rwx- */

Для приложения, не работающего с ACL-списками, это означает «Запретить доступ всем, кроме владельца файла». Такая семантика должна сохраняться даже при наличии ACL-списков. В случае отсутствия записи ACL_MASK данное поведение можно реализовать различными способами, но каждый из них сталкивается с трудностями (представлены ниже).

• Простого изменения записей ACL_GROUP_OBJ и ACL_USER_OBJ так, чтобы у них была маска —, окажется недостаточно, поскольку у пользователя paulh и у группы teach по-прежнему остались бы некоторые права доступа к файлу.

• Другой возможностью могло бы стать применение новой группы с иным набором прав доступа (то есть с полным запретом доступа) для всех записей ACL_USER, ACL_GROUP, ACL_GROUP_OBJ и ACL_OTHER в списке ACL:

user::rwx # ACL_USER_OBJ

user: paulh:- # ACL_USER

group::- # ACL_GROUP_OBJ

group: teach:- # ACL_GROUP

other::- # ACL_OTHER

Проблема такого подхода заключается в том, что приложение, которое не использует ACL-списки, могло бы непреднамеренно нарушить семантику прав доступа, установленную приложениями, применяющими ACL-списки, поскольку (например) следующий вызов не вернул бы записи ACL_USER и ACL_GROUP ACL-списка в их исходное состояние:

chmod(pathname, 751);