Прежде чем выяснять, как менять эффективный идентификатор процесса, рассмотрим, зачем это необходимо. Предположим, имеется серверный процесс, который может просматривать любой файл независимо от того, кто является его владельцем. Такой процесс должен быть запущен пользователем
root
, так как только у него есть подобные привилегии. А теперь допустим, что запрос к файлу поступает от конкретного пользователя (
mitchell
, к примеру). Серверный процесс может проверить, есть ли у данного пользователя соответствующие разрешения, но это означает дублирование того кода, который уже реализован в ядре.
Гораздо лучший подход — временно поменять эффективный идентификатор пользователя root на
mitchell
и попытаться выполнить требуемую операцию. Если пользователь
mitchell
не имеет нужных прав доступа, ядро само даст об этом знать. После завершения (или отмены) операции серверный процесс восстановит первоначальный эффективный идентификатор.
Механизм временной замены идентификаторов используется программами, которые выполняют аутентификацию пользователей, пытающихся зарегистрироваться в системе. Такие программы работают с правами пользователя
root
. Когда пользователь вводит свое имя и пароль, программа аутентификации сверяет их с записями в системной базе паролей. Если проверка прошла успешно, программа меняет свои эффективные и реальные идентификаторы на пользовательские, после чего выполняет функцию
exec
, которая запускает интерпретатор команд. В результате пользователь оказывается в среде интерпретатора, идентификаторы которого соответствуют пользовательским.
Функция, меняющая пользовательский идентификатор процесса, называется
setreuid
(имеется, конечно же, и функция
setregid
). Она принимает два аргумента: устанавливаемый реальный идентификатор и требуемый эффективный идентификатор. Вот как, к примеру, можно поменять эффективный и реальный идентификаторы:
setreuid(geteuid, getuid);
Естественно, ядро не позволит первому попавшемуся процессу изменить свои идентификаторы. Если бы это было возможно, любой пользователь легко мог бы получить доступ к чужим ресурсам, сменив эффективный идентификатор одного из своих процессов. Поэтому ядро делает исключение лишь для процессов, чей эффективный идентификатор пользователя равен нулю (опять-таки, обратите внимание на то, какой властью обладают процессы суперпользователя!) Всем остальным процессам разрешается следующее:
■ заменять эффективный идентификатор реальным;
■ заменять реальный идентификатор эффективным;
■ переставлять местами значения реального и эффективного идентификаторов.
Первый вариант будет использован серверным процессом, когда он закончит работать от имени пользователя
mitchell
и захочет снова "стать" пользователем
root
. Второй вариант используется программой аутентификации после того, как она сделала эффективный идентификатор равным пользовательскому. Изменение реального идентификатора необходимо для того, чтобы пользователь не смог стать обратно пользователем
root
. Последний, третий, вариант в современных программах не встречается.
В качестве любого из аргументов функции
setreuid
можно указать значение -1. Это означает, что соответствующий идентификатор нужно оставить без изменений. Есть также вспомогательная функция
seteuid
, которая меняет эффективный идентификатор, но не трогает реальный. Например, следующие две строки эквивалентны:
seteuid(id);
setreuid(-1, id);
10.4.1. Программы с установленным битом SUID
Выше было показано, как процесс пользователя
root
может временно принять на себя права другого пользователя или отказаться от специальных привилегий, изменив свои реальный и эффективный идентификаторы. Но вот загадка: может ли непривилегированный пользователь стать суперпользователем? Это кажется невозможным, но следующий пример свидетельствует об обратном:
% whoami
mitchell
% su
Password: ...
% whoami
root
Команда
whoami
аналогична команде
id
, но отображает только эффективный идентификатор пользователя. Команда
su
позволяет вызвавшему ее пользователю стать суперпользователем, если введен правильный пароль.
Как же работает команда
su
? Ведь мы знаем, что интерпретатор команд был запущен с реальным и эффективным идентификаторами, равными
mitchell
. Функция
setreuid
не позволит ему поменять ни один из них.
Дело в том, что у программы
su
установлен бит смены идентификатора пользователя (SUID, set user identifier). Это значит, что при запуске ее эффективным идентификатором станет идентификатор владельца (реальный идентификатор останется тем же, что у пользователя, запустившего программу). Для установки бита SUID предназначены команда
В качестве примера рассмотрим программу, показанную в листинге 10.3.
34
Существует также бит смены идентификатора группы (SGID, set group identifier). Программа c установленным битом SGID при запуске примет эффективный идентификатор группы, которой принадлежит файл.
Теперь предположим, что у программы установлен бит SUID и она принадлежит пользователю
root
. В этом случае вывод команды
ls
будет примерно таким:
– rwsrws--x 1 root root 11931 Jan 24 18:25 setuid-test
Буквы s в строке режима означают, что этот файл не только является исполняемым, но для него установлены также биты SUID и SGID. Результат работы программы будет таким:
% whoami
mitchell
% ./setuid-test
uid=501 euid=0
Обратите внимание на то, что эффективный идентификатор стал равным нулю. Устанавливать биты SUID и SGID позволяют команда
chmod u+s
и
chmod g+s
соответственно. Приведем пример:
% ls -l program
– rwxr-xr-x 1 samuel csl 0 Jan 30 23:38 program
% chmod g+s program
% ls -l program
– rwxr-sr-x 1 samuel csl 0 Jan 30 23:38 program
% chmod u+s program
% ls -l program
– rwsr-sr-x 1 samuel csl 0 Jan 30 23:38 program
Аналогичным целям служат флаги
S_ISUID
и
S_ISGID
функции
chmod
.
Именно так работает команда
su
. Ее эффективный идентификатор пользователя равен нулю. Если введенный пароль совпадает с паролем пользователя root, команда меняет свой реальный идентификатор на root, после чего запускает новый интерпретатор команд. В противном случае ничего не происходит.