11.2.2. Использование Sun rpc

Одной из самых распространенных реализаций RPC-технологии для UNIX-систем есть Sun RPC. К ее особенностям принадлежит реализация на основе TCP/IP, независимость от отображения данных у клиента и сервере.

Разработка файла спецификаций RPC

В документации Sun RPC не употребляют названия IDL, однако аналоги IDL-файлов и IDL-компилятора есть. IDL-файлами выступают файлы спецификаций RPC (с расширением .х), которые обрабатывает специальная утилита rpcgen.

В первую очередь в файле спецификаций RPC задают типы данных, которые используют в качестве параметры. Часть типов отвечает стандартным типам языка С, например, и nt или long, строчный тип определяют как string, максимальную длину строки задают в угловых дужках. Сложные типы данных задают структурами (тоже определенными по правилам языка С). Часто простым типам ставят в соответствие структуры, которые содержат единственное поле.

Кроме того, в этом файле задают спецификацию RPC-приложений. Она во многом подобная описанию интерфейса (набор объявлений процедур, объединенных общим именем). Каждой процедуре присваивают номер, уникальный в пределах спецификации, всему приложению отвечает номер версии и номер приложения (program number), которое является 32-битним числом, которое уникально идентифицирует RPC-cepвер в рамках системы. Для серверов пользователя этот номер должен быть в диапазоне 0x20000000- 0x3FFFFFFF.

Приведем пример файла спецификаций RPC для задания одной процедуры с одним параметром (допустимо, что этот файл имеет название myrpc.x).

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

Файл спецификаций RPC должен обрабатываться утилитой rpcgen:

$ rpcgen myrpc.х

В результате этого на основе myrpc.x образуются такие файлы:

• myrpc.h — объявление отдаленных процедур и типов, которые будут использованы в приложениях ;

• myrpc_clnt.c, myrpc_svc.c — коды клиентской и серверной заглушек;

• myrpc_xdr.c - код превращения типов в формат внешнего отображения (XDR), пригодный для пересылки сетью (этот файл компонуется вместе с клиентом и сервером).

Служба отображения портов Sun RPC

Эта служба является некоторым аналогом службы именования. Она отвечает за отображение между номерами приложений и TCP или UDP-портами и реализованная как фоновый процесс, который обычно называют portmapper.

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

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

Получить информацию о зарегистрированных приложениях можно с помощью утилиты rpcinfo.

$ rpcinfo -p имя_хоста

Разработка сервера

Особенностью Sun RPC является то, что в случае использования утилиты rpcgen никаких дополнительных шагов для разработки сервера, кроме создания кода отдаленных процедур, делать не нужно. Код функции main() для сервера, рядом с кодом серверной заглушки, генерирует rpcgen и помещает в файл myhello_svc.c. Этот код автоматически регистрирует сервер в службе отображения портов, переводит его в фоновый режим и переходит к ожиданию соединений.

Во время компиляции и компоновки сервера нужно использовать файлы с определениями сохраненных процедур, файл серверной заглушки myhello_svc.c и файл XDR-превращений myhello_xdr.c.

Разработка клиента

Перед вызовом процедуры на отдаленном сервере в коде клиента необходимо получить клиентский дескриптор, который будет использован дальше для вызова сохраненных процедур из сервера. Этот дескриптор является указателем на специальную структуру CLIENT. Для его получения используют функцию clnt_create()

#include <rpc/rpc.h>

CLIENT *clnt_create(const char *host, unsigned long pnum.

unsigned long ver. const char *protocol);

где: host - имя или IP-адрес отдаленного хоста;

pnum - номер приложения (в заглавном файле, згенерованому rpcgen, для него определяют соответствующую константу, например HELL0PR0G);

ver — номер версии (для него определяют аналогичную константу, например HELL0JER);

protocol — строка с названием протокола ("tcp", "udp").

Заглавный файл <rpc/rpc.h> будет автоматически подключен в myrpc.h, потому явно подключать его не обязательно.

#include "myrpc.h"

CLIENT *cl:

сl = clnt_create("myserver". HELL0_PR0G. HELLOJER. "tcp"):

По получении клиентского дескриптора можно вызывать отдаленную процедуру. Для этого вызывают процедуру имя_номер_версии(): для процедуры say-hello() нужно вызывать sayhello_1(). Все аргументы передают в эту функцию как указатели, последним аргументом дополнительно задают клиентский дескриптор.

struct rasg hello = { "hello world" };

void *res = sayhello_1(&hello. cl);

Вызов отдаленной процедуры может вернуть NULL: это значит, что произошла ошибка. Строку с информацией об ошибке в этом случае возвращает функция clnt_sperror(), которая первым параметром принимает клиентский дескриптор, а вторым — имя отдаленного хоста:

if (res == NULL)

printf("Ошибка: %s\n". clnt_sperror(cl. "myserver"));

Обеспечение безопасности данных в случае использования Sun RPC

Для обеспечения безопасности данных в случае использования RPC применяют аутентификацию RPC-клиентов перед доступом к серверу. Есть несколько уровней такой аутентификации.

Уровень AUTH_N0NE (используемый по умолчанию) значит, что аутентификацию не выполняют совсем. В соответствии с ним любой клиент в сети, которая может отсылать пакеты RPC-серверу, имеет возможность вызывать любую реализованную им процедуру. Этот уровень не обеспечивает никакой защиты и не рекомендованный к использованию.

Уровень AUTH_UNIX значит, что каждый RPC-запрос сопровождается идентификатором пользователя (uid) и набором идентификаторов групп (gid). Имеется в виду, что эти идентификаторы отвечают пользователю, который запустил клиентское приложение, и что сервер доверяет этому пользователю.

Этот уровень тоже не совсем отвечает современным представлением о сетевой безопасности, поскольку злоумышленник может создавать и отсылать RPC-пакеты с произвольными значениями uid и gid, и их авторство не может быть проверено сервером.

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

Уровень AUTH_DES использует гибридную криптосистему для организации защищенного канала связи для RPC-вызова. Реализация такого уровня аутентификации известна как Secure RPC.