Марк Митчелл - Программирование для Linux. Профессиональный подход
% ls -l hello
-rwxr-x--x 1 samuel csl 3 Jan 22 16:38 hello
Обратите внимание на появление буквы x в конце строки режима. Флаг о+x команды chmod означает добавление (+) права выполнения (x) для остальных пользователей (о). Если требуется, к примеру, отнять право записи у группы, следует задать такой флаг: g-w.
Функция stat() позволяет определить режим доступа к файлу программным путем. Она принимает два аргумента: имя файла и адрес структуры, заполняемой информацией о файле. Подробнее функция stat() описана в приложении Б, "Низкоуровневый ввод-вывод". Пример ее использования показан в листинге 10.2.
Листинг 10.2. (stat-perm.c) Проверка того, имеет ли владелец право записи в файл#include <stdio.h>
#include <sys/stat.h>
int main(int argc, char* argv[]) {
const char* const filename = argv[1];
struct stat buf;
/* Получение информации о файле. */
stat(filename, &buf);
/* Если владельцу разрешена запись в файл,
отображаем сообщение. */
if (buf.st_mode & S_IWUSR)
printf("Owning user can write '%s'.n", filename);
return 0;
}
Если запустить программу с файлом hello, будет выдано следующее:
% ./stat-perm hello
Owning user can write 'hello'.
Константа S_IWUSR соответствует праву записи для владельца. Для каждого бита в строке режима существует своя константа. Например, константа S_IRGRP обозначает право чтения для группы, а константа S_IXOTH — право выполнения для остальных пользователей. Если невозможно получить информацию о файле, функция stat() возвращает -1 и помещает код ошибки в переменную errno.
С помощью функции chmod() можно менять режим доступа к существующему файлу. Функции передаётся имя файла и набор флагов, соответствующих устанавливаемым битам доступа. Например, в следующей строке файл hello делается доступным для чтения и выполнения владельцу, а права группы и остальных пользователей отменяются:
chmod("hello", S_IRUSR | S_IXUSR);
Те же самые права доступа действуют и в отношении каталогов, но имеют несколько иной смысл. Если у пользователя есть право чтения каталога, то это означает разрешение на получение списка содержимого каталога. Право записи означает возможность добавлять и удалять файлы в каталоге. Пользователь, которому разрешена запись в каталог, может удалять из него файлы даже в том случае, когда у него нет права доступа к этим файлам. Право выполнения применительно к каталогам называется правом поиска. Пользователю. имеющему это право, разрешается входить в каталог и обращаться к его файлам. Если пользователь не может перейти в каталог, то ему не удастся получить доступ к находящимся в нем файлам независимо от их собственных прав доступа.
Подводя итог, рассмотрим, как ядро определяет, имеет ли процесс право обратиться к заданному файлу. Сначала выясняется, кем является пользователь, запустивший процесс: владельцем файла, членом его группы или кем-то другим. В зависимости от категории пользователя проверяется соответствующий набор битов чтения/записи/выполнения и на его основании принимается окончательное решение.[32]
Есть, правда, одно важное исключение: процессы, запускаемые пользователем root (его идентификатор равен нулю), всегда получают доступ к требуемым файлам независимо от их атрибутов.
10.3.1. Проблема безопасности: программы без права выполнения
Есть один хороший пример того, как обмануть неопытного пользователя, пытающегося защитить свои программы от несанкционированного запуска. Сброс бита выполнения файла еще не означает, что файл нельзя будет запустить. Дело в том, что при копировании файла копия переходит в распоряжение нового владельца. Как вы понимаете, ему не составляет никакого труда изменить права доступа к скопированному файлу и снова сделать его исполняемым. Вывод: защищайте программы не от несанкционированного запуска, а от несанкционированного копирования!
10.3.2. Sticky-бит
Помимо обычных битов режима есть один особый бит, называемый sticky-битом ("липучкой").[33] Он применим только в отношении каталогов.
Обычно удалять файлы могут пользователи, имеющие право записи в каталог. Каталог, для которого установлен sticky-бит, допускает удаление файла только в том случае, когда пользователь является владельцем этого файла или самого каталога и имеет право записи в каталог.
В типичной Linux-системе есть несколько таких каталогов. Один из них — каталог /tmp, в котором любой пользователь может размещать временные файлы. Этот каталог специально сделан доступным для всех пользователей, поэтому он полностью открыт для записи. Однако нельзя допустить, чтобы пользователи удаляли чужие файлы, поэтому для каталога /tmp установлен sticky-бит.
О наличии sticky-бита говорит буква t в конце строки режима:
% ls -ld /trap
drwxrwxrwt 12 root root 2048 Jan 24 17:51 /tmp
Соответствующий флаг функций stat() и chmod() называется S_ISVTX.
Если требуется установить для каталога sticky-бит. следует воспользоваться такой командой:
% chmod o+t каталог
А вот как можно назначить каталогу те же права доступа, что и к каталогу /tmp:
chmod(dir_path, S_IRWXU | S_IRWXG | S_IRWXO | S_ISVTX);
10.4. Реальные и эффективные идентификаторы
До сих пор подразумевалось, что у процесса — один идентификатор пользователя и один идентификатор группы. На самом деле не все так просто. У каждого процесса есть два пользовательских идентификатора: реальный и эффективный. То же самое справедливо и в отношении идентификаторов групп. В большинстве случаев ядро работает с эффективным идентификатором. Например, если процесс пытается открыть файл, ядро проверяет допустимость этой операции именно на основании эффективного идентификатора.
Упомянутые выше функции geteuid() и getegid() возвращают эффективные идентификаторы пользователя и группы. Для определения реальных идентификаторов предназначены функции getuid() и getgid().
Раз ядро работает только с эффективным идентификатором, какой смысл в существовании еще и реального идентификатора? Есть один специальный случай, когда он необходим: ядро проверяет его при попытке изменения эффективного идентификатора выполняющегося процесса.
Прежде чем выяснять, как менять эффективный идентификатор процесса, рассмотрим, зачем это необходимо. Предположим, имеется серверный процесс, который может просматривать любой файл независимо от того, кто является его владельцем. Такой процесс должен быть запущен пользователем root, так как только у него есть подобные привилегии. А теперь допустим, что запрос к файлу поступает от конкретного пользователя (mitchell, к примеру). Серверный процесс может проверить, есть ли у данного пользователя соответствующие разрешения, но это означает дублирование того кода, который уже реализован в ядре.
Гораздо лучший подход — временно поменять эффективный идентификатор пользователя root на mitchell и попытаться выполнить требуемую операцию. Если пользователь mitchell не имеет нужных прав доступа, ядро само даст об этом знать. После завершения (или отмены) операции серверный процесс восстановит первоначальный эффективный идентификатор.
Механизм временной замены идентификаторов используется программами, которые выполняют аутентификацию пользователей, пытающихся зарегистрироваться в системе. Такие программы работают с правами пользователя root. Когда пользователь вводит свое имя и пароль, программа аутентификации сверяет их с записями в системной базе паролей. Если проверка прошла успешно, программа меняет свои эффективные и реальные идентификаторы на пользовательские, после чего выполняет функцию exec(), которая запускает интерпретатор команд. В результате пользователь оказывается в среде интерпретатора, идентификаторы которого соответствуют пользовательским.
Функция, меняющая пользовательский идентификатор процесса, называется setreuid() (имеется, конечно же, и функция setregid()). Она принимает два аргумента: устанавливаемый реальный идентификатор и требуемый эффективный идентификатор. Вот как, к примеру, можно поменять эффективный и реальный идентификаторы:
setreuid(geteuid(), getuid());
Естественно, ядро не позволит первому попавшемуся процессу изменить свои идентификаторы. Если бы это было возможно, любой пользователь легко мог бы получить доступ к чужим ресурсам, сменив эффективный идентификатор одного из своих процессов. Поэтому ядро делает исключение лишь для процессов, чей эффективный идентификатор пользователя равен нулю (опять-таки, обратите внимание на то, какой властью обладают процессы суперпользователя!) Всем остальным процессам разрешается следующее:
