В программном коде ядра перечисленные выше проверки сконструированы таким образом, чтобы проверка привилегированности процесса выполнялась только в том случае, если процессу не предоставлены необходимые права доступа в результате какой-либо другой проверки. Это сделано во избежание излишней установки флага учета процессов ASU, который указывает на то, что данный процесс воспользовался привилегиями суперпользователя (см. раздел 28.1).
Проверки прав доступа для владельца, группы и остальных выполняются по порядку и прекращаются, как только обнаруживается применимое правило. Это может привести к неожиданным последствиям: если, например, права доступа для группы превышают права владельца, то последний будет фактически иметь меньше прав доступа к файлу, чем участники группы, как показано в следующем примере:
$ echo 'Hello world' > a.txt
$ ls — l a.txt
— rw-r-r- 1 mtk users 12 Jun 18 12:26 a.txt
$ chmod u-rw a.txt
$ ls — l a.txt
— r-r- 1 mtk users 12 Jun 18 12:26 a.txt
$ cat a.txt
cat: a.txt: Permission denied
$ su avr
Password:
$ groups
users staff teach cs
$ cat a.txt
Hello world
Подобные замечания применимы, если предоставлено больше прав доступа для остальных, чем для владельца или группы.
Поскольку информация о правах доступа к файлу и о его принадлежности содержится в индексном дескрипторе файла, все имена файлов (ссылки), которые указывают на один и тот же индексный дескриптор, будут совместно использовать эту информацию.
В Linux 2.6 реализованы списки контроля доступа (ACLs), позволяющие задавать права доступа к файлу для отдельного пользователя или группы. Если файл имеет такой список, то применяется измененная версия алгоритма, приведенного выше. Данные списки будут описаны в главе 17.
Проверка прав доступа для привилегированных процессов
Выше было сказано, что если процесс является привилегированным, то при проверке прав доступа ему предоставляется полный доступ. Необходимо добавить одну оговорку к этому утверждению. В случае с файлом, который не является каталогом, Linux предоставляет разрешение на выполнение для привилегированного процесса, только если такое разрешение предоставлено по меньшей мере одной категории прав доступа для данного файла. В ряде других реализаций UNIX привилегированный процесс может выполнять файл, даже если никакой из категорий не предоставлено разрешение на выполнение. При доступе к каталогу привилегированному процессу всегда предоставляется разрешение на выполнение (поиск).
Можно перефразировать наше описание привилегированного процесса в терминах двух возможностей процесса Linux: CAP_DAC_READ_SEARCH и CAP_DAC_OVERRIDE (см. раздел 39.2). Процесс с возможностью CAP_DAC_READ_SEARCH всегда обладает разрешением на чтение любого типа файла, а также всегда имеет права доступа на чтение и выполнение для каталога (то есть всегда может иметь доступ к файлам в каталоге и читать список файлов в каталоге). Процесс с возможностью CAP_DAC_OVERRIDE всегда обладает разрешением на чтение и запись любого типа файла, а также обладает разрешением на выполнение, если файл является каталогом или если разрешение на выполнение предоставлено по меньшей мере одной категории прав доступа для данного файла.
15.4.4. Проверка доступности файла: системный вызов access()
Как отмечалось в разделе 15.4.3,
Системный вызов access() проверяет доступность файла, указанного в аргументе pathname, на основе реальных идентификаторов пользователя и группы (а также идентификаторов добавочных групп) для процесса.
#include
int access(const char *
Возвращает 0, если предоставлены все права доступа, и –1 в противном случае
Если аргумент pathname является символической ссылкой, системный вызов access() разыменовывает ее.
