Искусство программирования для Unix

пользователя и выполняет оставшуюся часть командной строки от имени данного пользователя.

Создание цепей Бернштайна полезно в ситуациях, когда приложение требует setuid- или setgid- привилегий для инициализации соединения или для получения какого-либо мандата, а затем понижает эти привилегии, чтобы можно было использовать последующий вовсе не обязательно 'благонадежный' код. Поскольку дочерняя программа была запущена с помощью вызова exec, она не может установить свой действительный идентификатор пользователя равным идентификатору администратора. Такая методика является более гибкой, чем использование одного процесса, поскольку можно модифицировать поведение системы путем внедрения в цепочку другой программы.

Например, программа rblsmtpd (упомянутая выше) может быть вставлена в цепь Бернштайна между программой tcpserver (из пакета ucspi-tcp) и реальным SMTP-сервером, обычно qmail-smtpd. В то же время она также работает с inetd(8) и sendmail -bs.

7.2.5. Подчиненные процессы

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

Вызов popen(3) в Unix способен устанавливать либо канал ввода, либо канал вывода для подоболочки, но не оба канала для подчиненного процесса — видимо, для поощрения более простого программирования. И фактически интерактивный обмен данными между главным и подчиненным процессом является настолько сложным, что обычно используется только в ситуациях, когда (а) связанный протокол является крайне примитивным, либо (b) подчиненный процесс спроектирован для обмена данными по протоколу прикладного уровня в соответствии с принципами, которые описывались в главе 5. Данная проблема и способы ее разрешения рассматриваются в главе 8.

При написании пары 'главный-подчиненный' хорошей практикой считается заставить главный процесс поддерживать ключ командной строки или переменную среды, которая позволяет вызывающим программам устанавливать собственную подчиненную команду. Кроме прочего, это полезно для отладки. Нередко обнаруживается удобство такой конструкции во время разработки для вызова реального подчиненного процесса из тестовой программы, которая осуществляет мониторинг и протоколирование транзакций между главным и подчиненным процессом.

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

7.2.5.1. Учебный пример: scp и ssh

Индикаторы выполнения — один распространенный случай, в котором связанный протокол действительно является тривиальным. Утилита scp(1) (secure-copy command — команда безопасного копирования) вызывает программу ssh(1) как подчиненный процесс, перехватывая со стандартного вывода ssh достаточно информации для того, чтобы переформатировать отчеты в виде ASCII-анимации индикатора выполнения [71].

7.2.6. Равноправный межпроцессный обмен данными

Все рассмотренные выше методы обмена данными имеют некоторую неявную иерархию, в которой одна программа фактически контролирует или управляет другой, а в противоположном направлении сведения обратной связи не передаются или передаются в ограниченном количестве. В системах связи или сетях часто требуется создание равноправных (peer-to-peer) каналов, обычно (но не обязательно) поддерживающих свободную передачу данных в обоих направлениях. Ниже рассматриваются методы равноправного обмена данными, а несколько учебных примеров рассматривается в последующих главах.

7.2.6.1. Временные файлы

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

Наиболее очевидная проблема при использовании временных файлов в качестве IPC-методики заключается в мусоре, который остается в файловой системе, если обработка была прервана до того, как временный файл можно было удалить. Менее очевидный риск связан с коллизиями между несколькими экземплярами программы, использующими одно и то же имя временного файла. Именно поэтому для shell- сценариев является традиционным включение shell-переменной $$ в имена создаваемых ими временных файлов. В данной переменной содержится идентификатор процесса оболочки, и ее использование действительно гарантирует, что имя файла будет уникальным (такой же технический прием поддерживается в языке Perl).

Наконец, если атакующий знает расположение записываемого временного файла, то может переписать его и, вероятно, считать данные создавшего этот файл процесса или 'обмануть' использующий его процесс путем внедрения в файл модифицированных или фиктивных данных[72]. Это рискованно с точки зрения безопасности, а если задействованные процессы обладают привилегиями администратора, то риск представляется весьма серьезным. Его можно уменьшить с помощью тщательной настройки полномочий на каталог временных файлов, однако известно, что данные мероприятия, вероятно, приводят к утечкам.

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

7.2.6.2. Сигналы