UNIX Network Programming. Volume 2 Second Edition. Interprocess Communications

ПРИМЕЧАНИЕ

В большинстве реализаций определены шесть констант: MSG_R, MSG_W, SEM_R, SEM_A, SHM_R и SHM_W, показанные в табл. 3.3. Константы эти определяются в заголовочных файлах sys/msg.h, sys/sem.h и sys/shm.h. Однако стандарт Unix 98 не требует их наличия. Суффикс А в SEM_A означает «alter» (изменение).

Тройка функций getXXX не используют стандартную маску создания файла Unix. Разрешения очереди сообщений, семафора и разделяемой памяти устанавливаются в точности равными аргументу функции.

Posix IPC не дает создателю IPC возможности изменить владельца объекта. В Posix нет аналогов команды IPC_SET. Однако в Posix IPC имя объекта принадлежит файловой системе, и потому владелец может быть изменен привилегированным пользователем с помощью команды chown.

Когда какой-либо процесс предпринимает попытку доступа к объекту IPC, производится двухэтапная проверка: первый раз при открытии файла (функция getXXX) и затем каждый раз при обращении к объекту IPC:

1. При установке доступа к существующему объекту IPC с помощью одной из функций getXXX производится первичная проверка аргумента oflag, вызывающего функцию процесса. Аргумент не должен указывать биты доступа, не установленные в поле mode структуры ipc_perm (нижний квадрат на рис. 3.2). Например, процесс-сервер может установить значение члена mode для своей очереди входящих сообщений, сбросив биты чтения для группы и прочих пользователей. Любой процесс, попытавшийся указать эти биты в аргументе oflag функции msgget, получит ошибку. Надо отметить, что от этой проверки, производимой функциями getXXX, мало пользы. Она подразумевает наличие у вызывающего процесса информации о том, к какой группе пользователей он принадлежит: он может являться владельцем файла, может принадлежать к той же группе или к прочим пользователям. Если создающий процесс сбросит некоторые биты разрешений, а вызывающий процесс попытается их установить, функция getXXX вернет ошибку. Любой процесс может полностью пропустить эту проверку, указав аргумент oflag, равный 0, если заранее известно о существовании объекта IPC.

2. При любой операции с объектами IPC производится проверка разрешений для процесса, эту операцию запрашивающего. Например, каждый раз когда процесс пытается поместить сообщение в очередь с помощью команды msgsnd, производятся нижеследующие проверки (при получении доступа последующие этапы пропускаются).

 □ Привилегированному пользователю доступ предоставляется всегда.

 □ Если действующий идентификатор пользователя совпадает со значением uid или cuid объекта IPC и установлен соответствующий бит разрешения доступа в поле mode объекта IPC, доступ будет разрешен. Под соответствующим битом разрешения доступа подразумевается бит, разрешающий чтение, если вызывающий процесс запрашивает операцию чтения для данного объекта IPC (например, получение сообщения из очереди), или бит, разрешающий запись, если процесс хочет осуществить ее.

 □ Если действующий идентификатор группы совпадает со значением gid или cgid объекта IPC и установлен соответствующий бит разрешения доступа в поле mode объекта IPC, доступ будет разрешен.

 □ Если доступ не был разрешен на предыдущих этапах, проверяется наличие соответствующих установленных битов доступа для прочих пользователей.

3.6. Повторное использование идентификаторов

Структура ipc_perm (раздел 3.3) содержит переменную seq, в которой хранится порядковый номер канала. Эта переменная представляет собой счетчик, заводимый ядром для каждого объекта IPC в системе. При удалении объекта IPC номер канала увеличивается, а при переполнении сбрасывается в ноль.

ПРИМЕЧАНИЕ

В этом разделе мы описываем характерную для SVR4 реализацию. Стандарт Unix 98 не исключает использование других вариантов.