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

Дополнительные группы были представлены в 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, но выполняют действия по запросу пользователя, который может попытаться нарушить системную безопасность с помощью демонов.

ftp — хороший пример демона, который нуждается в гибком управлении uid. Изначально он запускается с правами root и затем переключает свой uid на uid пользователя, который подключился к нему (большинство систем запускают дополнительный процесс для обработки каждого ftp-запроса, поэтому такой подход работает достаточно хорошо). Это оставляет работу по проверке доступа к файлам ядру, к которому он относится. Однако в некоторых случаях демон ftp должен открывать сетевое подключение таким способом, который разрешен только root, поскольку пользовательские процессы не могут выдать сами себе административные полномочия (по вполне ясной причине), но сохранение идентификатора uid пользователя root вместо переключения на пользовательский uid должен потребовать от демона ftp самостоятельной проверки всего доступа к файловой системе. Решение этой дилеммы применяется симметрично — к обоим uid и первичным gid, поэтому мы и говорим здесь об uid.