• ACL_OTHER — эта запись определяет права доступа, предоставляемые пользователям, не соответствующим другим записям в списке контроля доступа. Каждый ACL-список содержит ровно одну такую запись. Она соответствует традиционным правам доступа для
Тег-спецификатор задействуется только для записей ACL_USER и ACL_GROUP. Он определяет либо идентификатор пользователя, либо идентификатор группы.
Одной из причин для различения минимального и расширенного ACL-списков является то, что последний обеспечивает семантическое расширение традиционной модели прав доступа. Еще одна причина связана с реализацией таких списков в Linux. Они реализованы как системные расширенные атрибуты (см. главу 16). EA, применяемый для организации списка контроля доступа к файлу, называется system.posix_acl_access. Этот атрибут необходим, только если у файла есть ACL-список. Информация о правах доступа для минимального списка может храниться (и действительно хранится) в обычных битах прав доступа к файлу.
Проверка прав доступа к файлу, который снабжен ACL-списком, выполняется при тех же условиях, что и в традиционной модели (см. подраздел 15.4.3). Проверки производятся в следующем порядке, пока не будет удовлетворен какой-либо из критериев.
1. Если процесс является привилегированным, то предоставляются все права. Существует одно исключение из этого утверждения, аналогичное описанному в подразделе 15.4.3 для традиционной модели прав доступа. Когда привилегированный процесс запускает выполняемый файл, такому процессу предоставляется право на выполнение, только если оно предоставлено по меньшей мере одной ACL-записью для данного файла.
2. При совпадении действующего UID для процесса с владельцем (идентификатором пользователя) файла этому процессу предоставляются права доступа, указанные в записи ACL_USER_OBJ. (Если выражаться точно, то в Linux для проверок, описанных в данном разделе, используются идентификаторы, относящиеся к файловой системе процесса, а не его действующие идентификаторы, как сказано в разделе 9.5.)
3. Если действующий UID совпадает с тегом-спецификатором в одной из записей ACL_USER, то данному процессу предоставляются права, указанные в этой записи, с применением маски (операции И) к значению ACL_MASK.
4. Если один из идентификаторов группы для процесса (то есть действующий GID или любой идентификатор дополнительной группы) совпадает с группой файла (это соответствует записи ACL_GROUP_OBJ) или с тегом-спецификатором какой-либо записи ACL_GROUP, то права доступа определяются на основе проверки следующих условий, пока не будет обнаружено совпадение:
1) если один из GID для процесса совпадает с группой файла, а запись ACL_GROUP_OBJ предоставляет требуемые права доступа, то данная запись определяет предоставляемые права. Они ограничиваются с учетом маски (операция И), примененной к значению ACL_MASK при его наличии;
2) если один из GID для процесса совпадает с тегом-спецификатором ACL_GROUP в записи для этого файла, а сама запись предоставляет требуемые права доступа, то данная запись определяет предоставленные права. Они ограничиваются с учетом маски (операция И), примененной к значению ACL_MASK;
3) в противном случае доступ запрещается.
5. В остальных случаях процессу предоставляются права доступа, указанные в записи ACL_OTHER.
Можно пояснить правила, относящиеся к GID, с помощью нескольких примеров. Допустим, у нас есть файл с идентификатором группы 100, причем этот файл защищен списком ACL, приведенным на рис. 17.1. Если бы процесс с GID 100 выполнил вызов access(file, R_OK), то этот вызов завершился бы успешно (то есть вернул бы 0). (Системный вызов access() описан в подразделе 15.4.4.) С другой стороны, несмотря на то, что запись ACL_GROUP_OBJ предоставляет все права доступа, вызов access(file, R_OK | W_OK | X_OK) завершился бы с ошибкой (то есть вернул бы –1 и значение EACCES для переменной errno), поскольку к правам доступа ACL_GROUP_OBJ применена маска (операция И) ACL_MASK, которая запрещает выполнение.
