Оставшийся аргумент, mode, содержит битовую маску, определяющую права доступа, необходимые для работы с новым объектом, если таковой создается в результате вызова (то есть если был указан флаг O_CREAT, а самого объекта еще не существовало). Значения, которые можно передать этому аргументу, такие же, как и в случае с файлами (см. табл. 15.4). По аналогии с системным вызовом open() к маске с правами доступа применяется атрибут umask процесса (см. подраздел 15.4.6). Пользовательские и групповые права владения новым объектом берутся из действующих идентификаторов пользователя и группы процесса, выполняющего IPC-вызов open. (Если быть предельно точным, в Linux владение новым объектом POSIX IPC определяется ID исполняемого файла, которые обычно совпадают с действующими идентификаторами; см. раздел 9.5.)
В реализациях, в которых IPC-объекты хранятся в обычной файловой системе, стандарт SUSv3 разрешает использовать GID родительского каталога в качестве идентификатора группы IPC-объекта.
Очереди сообщений и семафоры POSIX поддерживают IPC-вызов close, сигнализирующий о том, что вызывающий процесс завершил использование объекта и система может освободить любые связанные с ним ресурсы. Для закрытия объекта разделяемой памяти POSIX нужно удалить соответствующее отображение с помощью вызова munmap().
IPC-объекты автоматически закрываются, когда процесс завершает свою работу или выполняет вызов exec().
IPC-объекты имеют такую же маску с правами доступа, как и файлы, поэтому обращение к ним и к файлам ограничивается по одному и тому же принципу (см. подраздел 15.4.3). Различие только в том, что в случае с объектами POSIX IPC права на выполнение не имеют никакого смысла.
Начиная с версии 2.6.19, ядро Linux позволяет использовать списки контроля доступа для объектов разделяемой памяти и именованных семафоров POSIX. В настоящее время ACL-списки не поддерживаются для очередей сообщений POSIX.
Как и в случае с открытыми файлами, ядро ведет учет ссылок на объекты POSIX IPC. Это упрощает определение того, может ли объект быть удален безопасным образом.
Для каждого IPC-объекта предусмотрена операция unlink, аналогичная традиционному системному вызову unlink(), который применяется для файлов. Она немедленно удаляет имя объекта, а потом и сам объект, когда он перестает применяться другими процессами (то есть когда количество ссылок на него становится равным 0). В случае с очередями сообщений и семафорами это значит, что объект уничтожается после того, как его закроют все процессы; удаление объекта разделяемой памяти происходит, когда последний использовавший его процесс удалил отображение с помощью вызова munmap().
После операции удаления IPC-вызов open с тем же именем вернет дескриптор на новый объект (или ошибку, если не был указан флаг O_CREAT).
Как и в System V, объекты POSIX IPC хранятся на уровне ядра. После создания они продолжают существовать, пока не будут удалены или система не будет выключена. Таким образом, если процесс создаст объект, изменит его состояние и завершится, этот объект продолжит существовать и будет доступен для других процессов, запущенных позже.
Стандарт POSIX не предусматривает консольных команд для вывода и удаления IPC-объектов. Однако во многих системах, в том числе и Linux, IPC-объекты реализованы в рамках реальной или виртуальной файловой системы, подключенной где-то внутри корневого каталога (/), поэтому для их вывода и удаления можно использовать стандартные утилиты ls и rm (хотя стандарт SUSv3 не предусматривает такого их применения). Основной проблемой здесь является нестандартный формат имен IPC-объектов и их местоположение в рамках файловой системы.
В Linux объекты POSIX IPC находятся в виртуальных файловых системах, подключенных к каталогам, для которых установлен закрепляющий бит. Он запрещает удаление (см. подраздел 15.4.5); его наличие означает, что непривилегированный процесс может удалять только IPC-объекты, созданные им самим.
В Linux программы, применяющие механизмы POSIX IPC, должны быть скомпонованы с
POSIX IPC — это собирательное название трех IPC-механизмов: очередей сообщений, семафоров и разделяемой памяти. Все они разработаны в стандарте POSIX.1b в качестве альтернативы аналогичным средствам из System V.
Интерфейс POSIX IPC больше соответствует традиционной для UNIX файловой модели. IPC-объекты идентифицируются с помощью имен и управляются вызовами open, close и unlink, которые похожи на аналогичные системные вызовы для работы с файлами.