Если пакет wrapper компилировался в присутствии PROCESSOPTIONS в шаке-файле, синтаксис языка управления доступом изменяется и расширяется. Включение PROCESS_OPTIONS изменяет число полей в правилах. Новый синтаксис выглядит следующим образом:

список_служб : список_узлов : параметр : параметр ...

Списки узлов и служб определены так же, как в исходном варианте синтаксиса. Новым элементом являются параметры, равно как и факт, что в каждом правиле их может быть несколько. Существуют следующие параметры:

  • allow - Разрешает доступ к службе. Параметр указывается в конце правила.
  • deny - Запрещает доступ к службе. Параметр указывается в конце правила.
  • spawn команда - Выполняет указанную команду интерпретатора в порожденном процессе.
  • twist команда - Выполняет указанную команду интерпретатора вместо службы, к которой произошло обращение.
  • keepalive - Посылает сообщения keepalive удаленному узлу. Если узел не отвечает, соединение закрывается.
  • linger секунд - Указывает интервал времени, в течение которого следует пытаться доставить данные после того, как сервер закрыл соединение.
  • rfc931 [ интервал ] - Использует протокол IDENT для поиска имени пользователя на удаленном узле, интервал (timeout) определяет число секунд ожидания ответа от удаленного узла.
  • banners путь - Передает содержимое файла (сообщения) удаленной системе, путь - это имя каталога, содержащего файлы с «шапками» (banners). Отображается тот файл, имя которого совпадает с именем процесса сетевого демона.
  • nice [ число ] - Устанавливает значение приоритета выполнения (nice) для процесса сетевой службы. Значение по умолчанию - 10.
  • umask маска - Устанавливает значение umask для файлов, задействованных в работе процесса сетевой службы.
  • user пользователь[ группа] - Определяет идентификатор пользователя и идентификатор группы, с правами которых выполняется процесс сетевой службы. Данный параметр имеет более высокий приоритет, чем определения в файле inetd.conf.
  • setenv переменная значение - Устанавливает значение переменной среды выполнения процесса.

Чтобы проиллюстрировать отличия нового синтаксиса, рассмотрим ряд примеров, основанных на приводившихся ранее. В случае расширенного синтаксиса hosts.allow может содержать такие записи:

AL L : LOCAL, .wrotethebook.com : ALLOW
in.ftpd,in.telnetd : eds.oreilly.com : ALLOW
AL L : AL L : DENY

Новый синтаксис позволяет сократить количество файлов настройки до одного. Параметры ALLOW и DEN Y позволяют хранить все правила в одном файле. Первая строка разрешает доступ ко всем службам для всех локальных узлов и всех узлов домена wrotethebook.com. Вторая строка разрешает доступ к службам FTP и Telnet удаленному узлу eds.oreilly.com. Третья строка идентична правилу AL L : AL L в файле hosts.deny, она запрещает всем прочим узлам доступ ко всем службам. Параметры ALLOW и DEN Y позволяют переписать команду

ALL: .wrotethebook.com EXCEP T public.wrotethebook.com

следующим образом:

ALL: .wrotethebook.com : ALLOW
ALL: public.wrotethebook.com : DENY

Пример, включающий команду интерпретатора, в новом варианте выглядит почти так же:

in.rshd : ALL: spawn (safe_finger -1 @% h | /usr/sbin/mail ~s %d - %h root) & : DENY

Более интересная вариация на тему команд интерпретатора связана с параметром twist. Вместо того чтобы передавать команду интерпретатору для выполнения, команда twist выполняет для удаленного пользователя программу, но совсем не искомую. Например:

in.ftpd : ALL: twist /bin/echo 421 FT P not allowed from %h : DENY

В данном случае, когда удаленный пользователь обращается к демону FTP, вместо FTP запускается echo. Программа echo передает сообщение удаленной системе и разрывает соединение.

Расширенный синтаксис wrapper применяется редко, поскольку все задачи можно решить посредством традиционного синтаксиса. Следует разбираться в расширенном синтаксисе на случай встречи с ним, однако маловероятно, что вы испытаете необходимость его использовать. Альтернативой wrapper, которая вам встретится, будет xinetd. Этот демон заменяет inetd и позволяет управлять доступом. Основы работы с xinetd рассмотрены в главе 5. Здесь мы сосредоточим внимание на функциях управления доступом этого демона.