Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]

     

UNIX: взаимодействие процессов

Стивенс У.

Издано: Издательский дом "Питер"
ISBN: 5-318-00534-9
Твердый переплет, 576 стр.

Начало
Cодержание
Отрывок
[Заказать книгу в магазине "Мистраль"]

Отрывок

Глава 2

Posix IPC

2.1. Введение

Из имеющихся типов IPC следующие три могут быть отнесены к Posix IPC, то есть к методам взаимодействия процессов, соответствующим стандарту Posix:

  • очереди сообщений Posix (глава 5);
  • семафоры Posix (глава 10);
  • разделяемая память Posix (глава 13).

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

    Полный список функций, используемых для работы с данными типами IPC, приведен в табл. 2.1.

    2.2. Имена IPC

    В табл. 1.2 мы отметили, что три типа IPC стандарта Posix имеют идентификаторы (имена), соответствующие этому стандарту. Имя IPC передается в качестве первого аргумента одной из трех функций: mq_open, sem_open и shm_open, причем оно не обязательно должно соответствовать реальному файлу в файловой системе. Стандарт Posix.1 накладывает на имена IPC следующие ограничения:

  • Имя должно соответствовать существующим требованиям к именам файлов (не превышать в длину PATH_MAX байтов, включая завершающий символ с кодом 0).
  • Если имя начинается со слэша (/), вызов любой из этих функций приведет к обращению к одной и той же очереди. В противном случае результат зависит от реализации.
  • Интерпретация дополнительных слэшей в имени зависит от реализации.

    Таблица 2.1. Функции Posix IPC
    Очереди сообщений Семафоры Общая память
    Заголовочный файл <mqueue.h> <semaphore.h><sys/mman.h>
    Функции для создания,
    открытия и удаления
    mq_open
    mq_close
    mq_unlink
    sem_open
    sem_close
    sem_unlink
    sem_init
    sem_destroy
    shm_open
    shm_unlink
    Операции управления mq_getattr
    mq_setattr
    ftruncate
    fstat
    Операции IPC mq_send
    mq_receive
    mq_notify
    sem_wait
    sem_trywait
    sem_post
    sem_getvalue
    mmap
    munmap

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

    В системе Solaris 2.6 требуется наличие начального слэша и запрещается использование дополнительных. Для очереди сообщений, например, при этом создаются три файла в каталоге /tmp, причем имена этих файлов начинаются с .MQ. Например, если аргумент функции mq_open имеет вид /queue.1234, то созданные файлы будут иметь имена /tmp/.MQDqueue.1234, /tmp/.MQLqueue.1234 и /tmp/.MQPqueue.1234. В то же время в системе Digital Unix 4.0B просто создается файл с указанным при вызове функции именем.

    Проблема с переносимостью возникает при указании имени с единственным слэшем в начале: при этом нам нужно иметь разрешение на запись в корневой каталог. Например, очередь с именем /tmp.1234 допустима стандартом Posix и не вызовет проблем в системе Solaris, но в Digital Unix возникнет ошибка создания файла, если разрешения на запись в корневой каталог у программы нет. Если мы укажем имя /tmp/test.1234, проблемы в Digital Unix и аналогичных системах, создающих файл с указанным именем, пропадут (предполагается существование каталога /tmp и наличие у программы разрешения на запись в него, что обычно для большинства систем Unix), однако в Solaris использование этого имени будет невозможно.

    Для решения подобных проблем с переносимостью следует определять имя в заголовке с помощью директивы #define, чтобы обеспечить легкость его изменения при переносе программы в другую систему.

    ПРИМЕЧАНИЕ
    Разработчики стремились разрешить использование очередей сообщений, семафоров и разделяемой памяти для существующих ядер Unix и в независимых бездисковых системах. Это тот случай, когда стандарт получается чересчур общим и в результате вызывает проблемы с переносимостью. В отношении Posix это называется «как стандарт становится нестандартным».

    Стандарт Posix.1 определяет три макроса:
    S_TYPEISMQ(buf)
    S_TYPEISSEM(buf)
    S_TYPEISSHM(buf)
    которые принимают единственный аргумент — указатель на структуру типа stat, содержимое которой задается функциями fstat, lstat и stat. Эти три макроса возвращают ненулевое значение, если указанный объект IPC (очередь сообщений, семафор или сегмент разделяемой памяти) реализован как особый вид файла и структура stat ссылается на этот тип. В противном случае макрос возвращает 0.

    ПРИМЕЧАНИЕ
    К сожалению, проку от этих макросов мало, потому что нет никаких гарантий, что эти типы IPC реализованы как отдельные виды файлов. Например, в Solaris 2.6 все три макроса всегда возвращают 0.
    Все прочие макросы, используемые для проверки типа файла, имеют имена, начинающиеся с S_IS, и принимают всегда единственный аргумент: поле st_mode структуры stat. Поскольку макросы, используемые для проверки типа IPC, принимают аргументы другого типа, их имена начинаются с S_TYPEIS.

    Функция px_ipc_name

    Существует и другое решение упомянутой проблемы с переносимостью. Можно определить нашу собственную функцию px_ipc_name, которая добавляет требуемый каталог в качестве префикса к имени Posix IPC. #include "unpipc.h"
    char *px_ipc_name(const char *name);
    /* Возвращает указатель при успешном завершении, NULL при возникновении ошибки */

    ПРИМЕЧАНИЕ
    Так выглядят листинги наших собственных функций, то есть функций, не являющихся стандартными системными. Обычно включается заголовочный файл unpipc.h (листинг В.1).

    Аргумент name (имя) не должен содержать слэшей. Тогда, например, при вызове px_ipc_name("test1") будет возвращен указатель на строку /test1 в Solaris 2.6 или на строку /tmp/test1 в Digital Unix 4.0B. Память для возвращаемой строки выделяется динамически и освобождается вызовом free. Можно установить произвольное значение переменной окружения PX_IPC_NAME, чтобы задать другой каталог по умолчанию.

    В листинге 2.11 приведен наш вариант реализации этой функции.

    ПРИМЕЧАНИЕ
    Возможно, в этом листинге вы в первый раз встретитесь с функцией snprintf. Значительная часть существующих программ используют вместо нее функцию sprintf, однако последняя не производит проверки переполнения приемного буфера. В отличие от нее snprintf получает в качестве второго аргумента размер приемного буфера и впоследствии предотвращает его переполнение. Умышленное переполнение буфера программы, использующей sprintf, в течение многих лет использовалось хакерами для взлома систем.

    Функция snprintf еще не является частью стандарта ANSI C, но планируется ее включение в обновленный стандарт, называющийся C9X. Тем не менее многие производители включают ее в стандартную библиотеку С. Везде в тексте мы используем функцию snprintf в нашем собственном варианте, обеспечивающем вызов sprintf, если в системной библиотеке функция snprinft отсутствует.

    Листинг 2.1. Функция px_ipc_name в нашей реализации.

    // lib/px_ipc_name.c
    1 #include "unpipc.h"
    2 char *
    3 px_ipc_name(const char *name)
    4 {
    5 char *dir, *dst, *slash;
    6 if ( (dst = malloc(PATH_MAX)) == NULL)
    7 return(NULL); 8 /* есть возможность задать другое имя каталога с помощью переменной окружения */
    9 if ( (dir = getenv("PX_IPC_NAME")) == NULL) {
    10 #ifdef POSIX_IPC_PREFIX
    11 dir = POSIX_IPC_PREFIX; /* из "config.h" */
    12 #else
    13 dir = "/tmp/"; /* по умолчанию */
    14 #endif
    15 }
    16 /* имя каталога должно заканчиваться символом '/' */
    17 slash = (dir[strlen(dir) - 1] == '/') ? "" : "/";
    18 snprintf(dst, PATH_MAX, "%s%s%s", dir, slash, name);
    19 return(dst); /* для освобождения этого указателя можно вызвать free() */
    20 }

    2.3. Создание и открытие каналов IPC

    Все три функции, используемые для создания или открытия объектов IPC: mq_open, sem_open и shm_open, — принимают специальный флаг oflag в качестве второго аргумента. Он определяет параметры открытия запрашиваемого объекта аналогично второму аргументу стандартной функции open. Все константы, из которых можно формировать этот аргумент, приведены в табл. 2.2.

    Таблица 2.2. Константы, используемые при создании и открытии объектов IPC
    Описаниеmq_open sem_open shm_open
    Только чтение O_RDONLY O_RDONLY
    Только запись O_WRONLY
    Чтение и запись O_RDWR O_RDWR
    Создать, если не существует O_CREAT O_CREAT O_CREAT
    Исключающее создание O_EXCL O_EXCL O_EXCL
    Без блокировки O_NONBLOCK
    Сократить (truncate) существующий O_TRUNC

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

    Указание прочих флагов из табл. 2.2 не является обязательным.

    O_CREAT — создание очереди сообщений, семафора или сегмента разделяемой памяти, если таковой еще не существует (см. также флаг O_EXCL, влияющий на результат).

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

    Таблица 2.3. Константы режима доступа при создании нового объекта IPC
    Константа Описание
    S_IRUSR Владелец — чтение
    S_IWUSR Владелец — запись
    S_IRGRP Группа — чтение
    S_IWGRP Группа — запись
    S_IROTH Прочие — чтение
    S_IWOTH Прочие — запись

    Эти константы определены в заголовке <sys/stat.h>. Указанные биты разрешений изменяются наложением маски режима создания файлов для данного процесса (с. 83–85 [21]) или с помощью команды интерпретатора umask.

    Как и со вновь созданным файлом, при создании очереди сообщений, семафора или сегмента разделяемой памяти им присваивается идентификатор пользователя, соответствующий действующему (effective) идентификатору пользователя процесса. Идентификатор группы семафора или сегмента разделяемой памяти устанавливается равным действующему групповому идентификатору процесса или групповому идентификатору, установленному по умолчанию для системы в целом. Групповой идентификатор очереди сообщений всегда устанавливается равным действующему групповому идентификатору процесса (на с. 77–78 [21] рассказывается о групповых и пользовательских идентификаторах более подробно).

    ПРИМЕЧАНИЕ
    Кажется странным нал/bичие разницы в установке группового идентификатора для разных видов Posix IPC. Групповой идентификатор нового файла, создаваемого с помощью функции open, устанавливается равным либо действительному идентификатору группы процесса, либо идентификатору группы каталога, в котором создается файл, но функции IPC не могут заранее предполагать, что для объекта IPC создается реальный файл в файловой системе.

    O_EXCL — если этот флаг указан одновременно с O_CREAT, функция создает новую очередь сообщений, семафор или объект разделяемой памяти только в том случае, если таковой не существует. Если объект уже существует и указаны флаги O_CREAT | O_EXCL, возвращается ошибка EEXIST.

    Проверка существования очереди сообщений, семафора или сегмента разделяемой памяти и его создание (в случае отсутствия) должны производиться только одним процессом. Два аналогичных флага имеются и в System V IPC, они описаны в разделе 3.4.

    O_NONBLOCK — этот флаг создает очередь сообщений без блокировки. Блокировка обычно устанавливается для считывания из пустой очереди или записи в полную очередь. Об этом более подробно рассказано в подразделах, посвященных функциям mq_send и mq_receive раздела 5.4.

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

    На рис. 2.1 показана реальная последовательность логических операций при открытии объекта IPC. Что именно подразумевается под проверкой разрешений доступа, вы узнаете в разделе 2.4. Другой подход к изображенному на рис. 2.1 представлен в табл. 2.4.

    Рис. 2.1. Логика открытия объекта IPC

    Обратите внимание, что в средней строке табл. 2.4, где задан только флаг O_CREAT, мы не получаем никакой информации о том, был ли создан новый объект или открыт существующий.

    Таблица 2.4. Логика открытия объекта IPC O_CREAT | O_EXCL
    Аргумент oflag Объект не существует Объект уже существует
    Нет специальных флагов Ошибка, errno=ENOENT OK, открывается
    существующий объект
    O_CREAT OK, создается новый объект OK, открывается
    существующий объект
    OK, создается новый объект Ошибка, errno=EEXIST

    2.4. Разрешения IPC

    Новая очередь сообщений, именованный семафор или сегмент разделяемой памяти создается функциями mq_open, sem_open и shm_open, при условии, что аргумент oflag содержит константу O_CREAT. Согласно табл. 2.3, любому из данных типов IPC присваиваются определенные права доступа (permissions), аналогичные разрешениям доступа к файлам в Unix.

    При открытии существующей очереди сообщений, семафора или сегмента разделяемой памяти теми же функциями (в случае, когда не указан флаг O_CREAT или указан O_CREAT без O_EXCL и объект уже существует) производится проверка разрешений:

    1. Проверяются биты разрешений, присвоенные объекту IPC при создании.

    2. Проверяется запрошенный тип доступа (O_RDONLY, O_WRONLY, O_RDWR).

    3. Проверяется действующий идентификатор пользователя вызывающего процесса, действующий групповой идентификатор процесса и дополнительные групповые идентификаторы процесса (последние могут не поддерживаться).

    Большинством систем Unix производятся следующие конкретные проверки:

    1. Если действующий идентификатор пользователя для процесса есть 0 (привилегированный пользователь), доступ будет разрешен.

    2. Если действующий идентификатор пользователя процесса совпадает с идентификатором владельца объекта IPC: если соответствующий бит разрешения для пользователя установлен, доступ разрешен, иначе в доступе отказывается.

    Под соответствующим битом разрешения мы подразумеваем, например, бит разрешения на чтение, если процесс открывает объект только для чтения. Если процесс открывает объект для записи, должен быть установлен соответственно бит разрешения на запись для владельца (user-write).

    3. Если действующий идентификатор группы процесса или один из дополнительных групповых идентификаторов процесса совпадает с групповым идентификатором объекта IPC: если соответствующий бит разрешения для группы установлен, доступ будет разрешен, иначе в доступе отказывается.

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

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

    ПРИМЕЧАНИЕ
    Согласно табл. 2.2, функция sem_open не использует флаги O_RDONLY, O_WRONLY, O_RDWR. В разделе 10.2, однако, будет сказано о том, что некоторые реализации Unix подразумевают наличие флага O_RDWR, потому что любое обращение к семафору подразумевает чтение и запись его значения.

    2.5. Резюме

    Три типа Posix IPC — очереди сообщений, семафоры и разделяемая память — идентифицируются их полными именами. Они могут являться или не являться реальными именами файлов в файловой системе, и это вызывает проблемы с переносимостью. Решение проблемы — использовать собственную функцию px_ipc_name.

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

    Упражнения

    1. Каким образом биты установки идентификатора пользователя (set-user-ID, SUID) и установки идентификатора группы (set-group-ID) (раздел 4.4 [21]) программы, использующей Posix IPC, влияют на проверку разрешений, описанную в разделе 2.4?

    2. Когда программа открывает объект IPC, как она может определить, был ли создан новый объект IPC или производится обращение к существующему объекту?

  • Начало
    Cодержание
    Отрывок
    [Заказать книгу в магазине "Мистраль"]

     

    Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

    Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

    Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

    Виртуальные VPS серверы в РФ и ЕС

    Dedicated серверы в РФ и ЕС

    По промокоду CITFORUM скидка 30% на заказ VPS\VDS

    VPS/VDS серверы. 30 локаций на выбор

    Серверы VPS/VDS с большим диском

    Хорошие условия для реселлеров

    4VPS.SU - VPS в 17-ти странах

    2Gbit/s безлимит

    Современное железо!

    Новости мира IT:

    Архив новостей

    IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
    тел. +7 495 7861149
    Пресс-релизы — pr@citforum.ru
    Обратная связь
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...