Разработка приложений в среде Linux. Второе издание

Троан Эрик В.

10.2 Атрибуты процессов

10.2.1. Идентификатор процесса и происхождение

Два из наиболее фундаментальных атрибутов — это идентификатор процесса (process ID), или pid, а также идентификатор его родительского процесса. Идентификатор pid — это положительное целое число, которое уникально идентифицирует работающий процесс и сохраняется в переменной типа

pid_t

. Когда создается новый процесс, исходный процесс, известный как родитель нового процесса, будет уведомляться, когда этот дочерний процесс будет завершен.

Когда процесс "умирает", его код возврата сохраняется до тех пор, пока родительский процесс не запросит его. Состояние

завершения сохраняется в таблице процессов ядра, что заставляет ядро сохранять единицу процесса активной до тех пор, пока оно не сможет безопасно отбросить это состояние завершения. Процессы, которые завершились, но сберегаются для предохранения их состояния завершения, называются зомби. Как только состояние завершения такого зомби получено, он удаляется из таблицы процессов системы.

Если родитель процесса завершается (делая дочерний процесс висячим), такой процесс становится дочерним для начального процесса (init). Начальный процесс — это первый процесс, который запускается при загрузке машины и которому присваивается значение pid, равное 1. Одной из основных задач начального процесса является сбор кодов завершения процессов, чьи родители исчезли, позволяя ядру удалять такие дочерние процессы из таблицы процессов системы. Процессы могут получать свой pid и pid родителя с помощью функций

getpid

и

getppid

.

pid_t getpid(void)	Возвращает pid текущего процесса.
pid_t getppid(void)	Возвращает pid родительского процесса.

10.2.2. Сертификаты

В Linux используются традиционные механизмы обеспечения безопасности Unix для пользователей и групп. Идентификаторы пользователя (uid) и группы (gid) — это целые числа [16] , которые отображаются на символические имена пользователей и групп в файлах

/etc/passwd

и

/etc/group

, соответственно (более подробную информацию о базах данных пользователей и групп можно получить в главе 28). Однако ядро ничего не знает об именах — оно имеет дело только с целочисленными представлениями. Идентификатор uid, равный 0, зарезервирован за системным администратором, обычно имеющим имя root. Все обычные проверки безопасности отключаются для процессов, запущенных от имени root (то есть с uid, равным 0), что дает администратору полный контроль над системой.

16

uid и gid обычно представляют собой положительные целые, но отрицательные целые тоже имеют определенное назначение. Применение -1 для идентификатора проблематично, однако многие системные вызовы, работающие с uid и gid, используют

– 1

в качестве признака, что модифицировать значение не нужно (см. пример этого в

setregid

далее в главе).

В большинстве случаев процесс имеет единственный uid и единственный gid, ассоциированный с ним. Это идентификаторы, которые используются для большинства целей обеспечения безопасности (как, например, назначение прав владения вновь созданным файлам). Системные вызовы, которые могут модифицировать принадлежность процессов, обсуждаются далее в настоящей главе.

Со времен разработки Unix ограничение процессов принадлежностью к одной группе создало новые трудности. Пользователи, работающие со многими проектами, должны явно переключать свой gid, когда им нужен доступ к файлам, доступ к которым ограничен определенной группой пользователей.

Дополнительные группы были представлены в BSD 4.3 для решения этой проблемы. Хотя каждый процесс по-прежнему имеет собственный первичный gid (который используется, например, как gid для вновь создаваемых файлов), он также связан с набором дополнительных групп. Проверки безопасности, которые используются для обеспечения того, что процесс относится к определенной группе (и только этой группе), теперь позволяет обеспечить доступ и в случае, когда данная группа является одной из дополнительных групп, к которым процесс относится. Макрос

sysconf

по имени

_SC_NGROUPS_МАХ

специфицирует, к скольким дополнительным группам может относиться процесс. (Подробно о

sysconf

см. главу 6.) В Linux 2.4 и более ранних версиях

_SC_NGROUPS_MAX

был равен 32. В Linux 2.6 и последующих версиях

_SC_NGROUPS_MAX

равен 65536. Не используйте статические массивы для хранения дополнительных групп. Вместо этого выделяйте память динамически, принимая во внимания значение, возвращаемое

sysconf(_SC_NGROUPS_MAX)

. Старый код может пользоваться макросом

NGROUPS_MAX

для определения количества поддерживаемых групп, установленных в системе. Этот макрос не обеспечивает корректную работу, когда код компилируется в одной среде, а используется в другой.

Установка списка групп для процесса осуществляется системным вызовом

setgroups

и может быть выполнена процессом, имеющим полномочия root.

int setgroups(size_t num, const gid_t * list);

Параметр

list

указывает на массив из

num

идентификаторов групп gid. Дополнительная группа процесса устанавливается этим списком идентификаторов групп, переданным в массиве

list

.

Функция

getgroups

позволяет получить список дополнительных групп, установленных для процесса.

int getgroups(size_t num, gid_t * list);

list

должен указывать на массив элементов типа

gid_t

, который наполняется идентификаторами дополнительной группы процесса, a

num

определяет, сколько элементов может типа

gid_t

содержать

list

. В случае ошибки системный вызов

getgroups

возвращает

– 1

(обычно это происходит, когда

list

недостаточно велик, чтобы вместить дополнительный список групп процесса), или же количество дополнительных групп. В особом случае, когда

num

равно 0,

getgroups

просто возвращает количество дополнительных групп процесса.

Ниже показан пример использования

getgroups

.

gid_t *groupList;

int numGroups;

numGroups = getgroups(0, groupList);

if (numGroups) {

 groupList = alloca(numGroups * sizeof(gid_t));

 getgroups(numGroups, groupList);

}

Более сложный пример

getgroups

приведен в главе 28.

Таким образом, процесс имеет uid, первичный gid и набор дополнительных групп, ассоциированных с ним. К счастью, это все, о чем нужно знать большинству программистов. Существуют два класса программ, которым необходимо очень гибкое управление идентификаторами пользователей и групп — это программы setuid/setgid и системные демоны.

Системные демоны — это программы, которые всегда запущены в системе и выполняют определенные действия в ответ на внешние воздействия. Например, большинство демонов World Wide Web (

http

) функционируют всегда, ожидая подключения к ним клиента, чтобы обрабатывать клиентские запросы. Другие демоны, такие как

cron

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