Читать онлайн «Linux программирование в примерах». Страница 102

Противоположными опциями монтирования являются nogrpid и sysvgroups. Это поведение по умолчанию; однако, бит setgid. если он есть, все равно учитывается. (Здесь также оба имени означают одно и то же.)

POSIX устанавливает, что новые файлы и каталоги наследуют либо эффективный GID создающего процесса, либо группу родительского каталога. Однако, реализации должны предусмотреть способ заставить новые каталоги наследовать группу родительского каталога. Более того, стандарт рекомендует, чтобы приложения не полагались на то или иное поведение, но в случаях, когда это имеет значение, использовали chown() для принудительного назначения желательного GID для группы нового файла или каталога.

«Липкий» бит ведет начало от версий Unix для PDP-11, он использовался с обычными исполняемыми файлами[119]. Этот бит использовался с программами, которые предназначались для интенсивного использования, такими, как оболочка и редактор. Когда у программы был установлен этот бит, ядро хранило копию исполняемого кода программы на устройстве подкачки, из которого ее можно было быстро загрузить в память для повторного использования. (Загрузка из файловой системы занимает больше времени образ на устройстве подкачки хранился в смежных дисковых блоках, тогда как образ в файловой системе мог быть разбросан по всему диску). Исполняемые образы были «приклеены» к устройству подкачки, отсюда и название.

Таким образом, даже если программа в настоящее время не использовалась, предполагалось, что она вскоре могла быть использована другим пользователем, поэтому она могла быть быстро загружена.

В современных системах значительно более быстрые дисковое оборудование и память, чем в давнишней PDP-11. Они используют также методику, называемую подкачка по требованию, для загрузки в память лишь тех частей исполняемой программы, которые выполняются. Таким образом, сегодня «липкий» бит обычных исполняемых файлов не служит никаким целям и на самом деле ни на что не влияет.

Однако, в разделе 1.1.2 «Каталоги и имена файлов» мы упомянули, что «липкий» бит в каталоге, запись в который в других отношениях разрешена, предотвращает удаление файлов из этого каталога и их переименование любым пользователем, кроме владельца файла или root. Вот пример:

$ ls -ld /tmp /* Показать права доступа к /tmp */

drwxrwxrwt 19 root root 4096 Oct 20 14:04 /tmp

$ cd /tmp /* Перейти туда */

$ echo this is my file > arnolds-file /* Создать файл */

$ ls -l arnolds-file /* Показать его права доступа */

-rw-r--r-- 1 arnold devel 16 Oct 20 14:14 arnolds-file

$ su - miriam /* Смена пользователя */

Password:

$ cd /tmp /* Перейти в /tmp */

$ rm arnolds-file /* Попытка удаления файла */

rm: remove write-protected regular file 'arnolds-file'? y

 /* rm предупреждает */

rm: cannot remove 'arnolds-file': Operation not permitted

 /* Ядро запрещает удаление */

Основным назначением этой особенности является как раз использование в таких каталогах, как /tmp, куда хотят помещать свои файлы множество пользователей. С одной стороны, каталог должен иметь права записи для всех, чтобы каждый мог создавать там свои файлы. С другой стороны, раз запись разрешена для всех, любой пользователь может удалять файлы всех остальных пользователей! «Липкий» бит каталога красиво решает эту проблему. Для добавления к файлу или каталогу «липкого» бита используйте 'chmod +t':

$ mkdir mytmp /* Создать каталог */

$ chmod a+wxt mytmp /* Добавить права записи для всех и «липкий» бит */

$ ls -ld mytmp /* Проверить результат */

drwxrwxrwt 2 arnold devel 4096 Oct 20 14:23 mytmp

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

Все становится интереснее, когда процессу приходится менять значения UID и GID. Установка набора групп проста. Изменение значений действительных и эффективных UID и GID сложнее.

Функция setgroups() устанавливает новый набор групп:

#include <sys/types.h> /* Common */

#include <unistd.h>

#include <grp.h>

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

Параметр size указывает, сколько элементов в массиве list. Возвращаемое значение равно 0, если все было нормально, и -1 с установленным errno в противном случае.

В отличие от функций для манипулирования значениями действительных и эффективных UID и GID, эту функцию может вызвать лишь процесс, действующий как root. Это один пример того, что POSIX называет привилегированной операцией; сама она как таковая не стандартизуется POSIX.

setgroups() используется любой программой, которая осуществляет регистрацию в системе, такой как /bin/login для регистрации в консоли и /bin/sshd для удаленной регистрации с помощью ssh.

Работа с двумя различными ID пользователей представляет для программиста приложения проблему. Могут быть вещи, которые программе нужно сделать, работая с эффективным UID, а другие вещи — работая с действительным UID.

Например, до того, как в системах Unix появилось управление заданиями, многие программы предоставляли переходы в оболочку, т.е. способ запуска команды или интерактивной оболочки из текущей программы. Хорошим примером этого является редактор ed: набор командной строки, начинающейся с '!', запускает оставшуюся часть строки в качестве команды оболочки. Набрав '!sh', вы получаете интерактивную оболочку. (Это работает до сих пор — попробуйте!) Предположим, описанная ранее гипотетическая игровая программа также предоставляет переход в оболочку: она должна быть запущена от имени действительного пользователя, а не эффективного. В противном случае, редактирование файла счета или многие гораздо худшие вещи становятся для игрока тривиальной задачей!

Таким образом, имеется явная потребность в возможности замены эффективного UID действительным UID. Более того, полезна возможность обратного переключения эффективного UID на первоначальный. (В этом причина необходимости наличия сохраненного set-user ID; появляется возможность восстановления первоначальных привилегий, которые были у процесса при его запуске.)

Как и для множества Unix API, различные системы решили проблему разными способами, иногда с использованием одного и того же API, но с другой семантикой, а иногда введением другого API. Погружение в исторические подробности годится лишь для создания головной боли, поэтому мы не будем с этим беспокоиться. Вместо этого мы рассмотрим, что предоставляет POSIX и как работает каждый API. Более того, наше обсуждение фокусируется на значениях действительных и эффективных UID; значения GID работают аналогичным образом, поэтому мы не будем хлопотать с повторением подробностей для этих системных вызовов. Функции следующие:

#include <sys/types.h> /* POSIX */

#include <unistd.h>

int seteuid(uid_t euid); /* Установка эффективного ID */

int setegid(gid_t egid);

int setuid(uid_t uid);

 /* Установка эффективного ID, root устанавливает все */

int setgid(gid_t gid);

int setreuid(uid_t ruid, uid_t euid);

 /* Совместимость с BSD, устанавливаются оба */

int setregid(gid_t rgid, gid_t egid);

Есть три набора функций. Первые два были созданы POSIX:

int seteuid(uid_t euid)

Эта функция устанавливает лишь эффективный UID. Обычный пользователь (не root) может установить в качестве ID лишь в значения действительного, эффективного или сохраненного set-user ID. Приложения, которые будут переключать эффективный UID. должны использовать исключительно эту функцию.

Процесс с эффективным UID, равным нулю, может установить в качестве эффективного UID любое значение. Поскольку в качестве значения эффективного UID можно установить также сохраненный set-user ID, процесс может восстановить свои привилегии root с помощью другого вызова seteuid().

int setegid(gid_t egid)

Эта функция делает для эффективного ID группы то, что seteuid() делает для эффективного ID пользователя.

Следующий набор функций предлагает первоначальный API Unix для изменения действительных и эффективных UID и GID. В модели POSIX эти функции являются тем. что должна использовать программа с setuid-root для постоянного изменения действительного или эффективного UID: