Листинг 16.7 (продолжение)

10 err quit( usage: client <hostname> <integer-value> );

11 cl = Clnt create(argv[l]. SQUARE PROG. SQUAREJERS. tcp ):

12 auth destroy(cl->cl auth):

13 cl->cl auth = authsys create default():

14 in.argl = atoi(argv[2]):

15 if (squareproc 2(&in. &out. cl) != RPC SUCCESS)

16 err quit( *s . clnt sperror(cl. argv[l]));

17 printf( result: *ld\n . out.resl):

18 exitCO):

19 }

12-13 Эти строки были добавлены в данной версии программы. Сначала мы вызываем auth clestroy для удаления предыдущей аутентификационной информации, связанной с данным дескриптором клиента (то есть дескриптор нулевой аутентификации, создаваемый по умолчанию). Затем вызов authsys create clefault создает соответствующую аутентификационную структуру Unix и мы сохраняем ее в поле cl auth структуры CLIENT. Оставшаяся часть клиента не претерпела изменений по сравнению с листингом 16.5.

В листинге 16.8 приведен текст процедуры сервера, измененный по сравне-ниюс листингом 16.6. Мы не приводим текст процедуры square prog 2 freeresult, которая не меняется.

Листинг 16.8. Процедура сервера, запрашивающая аутентификацию Unix

sunrpc/square4/server.c

1 #include unpipcli

2 #include square.h

3 bool t

4 squareproc 2 svc(square in *inp. square out *outp. struct svc req *rqstp)

6 printfC thread Xй started, arg = auth = d\n .

7 pr threadJd(NULL). inp->argl. rqstp->rq cred.oa flavor):

8 if (rqstp->rq cred.oa flavor == AUTH SYS) {

9 struct authsys parms *au:

10 au = (struct authsys parms *)rqstp->rq clntcred:

11 printfC AUTH SYS: host Xs. uid ld, gid ld\n .

12 au->aup machname. (long) au->aup uid. (long) au->aup gid):

13 }

14 sleep(5):

15 outp->resl = inp->argl * inp->argl:

16 printf( thread ld done\n . pr thread id(NULL)):

17 return(TRUE);

18 }

6-8 Теперь мы используем указатель на структуру svc req, которая всегда передается в качестве одного из аргументов процедуры сервера:

struct svc req {

u long rq prog: /* номер программы */

u long rq vers: /* номер версии */

ujong rq proc: /* номер процедуры */

struct opaque auth rq cred;/* данные о клиенте */

caddrj rq clntcred; /* готовые данные (только для чтения) */

SVCXPRT *rq xprt: /* транспортный дескриптор */

struct opaque auth {

enumj oa flavor; /* flavor: константа AUTH xxx */

caddrj oa base: /* адрес дополнительной аутентификационной информации

ujnt oa length: /* не должно превосходить MAX AUTH BYTES */

};

Поле rq crecl содержит неформатированную информацию о клиенте, а его поле oa flavor содержит целое число, определяющее тип аутентификации. Термин неформатированная означает, что библиотека не обработала информацию, на которую указывает oa base. Но если тип идентификации относится к одному из поддерживаемых библиотекой, то в готовой информации о клиенте, на которую указывает rq cl ntcred, содержится некоторая структура, соответствующая данному типу аутентификации. Программа выводит тип аутентификации и прове-9-12ряет, соответствует ли он AUTH SYS.

Для аутентификации Unix указатель на готовую информацию (rq cl ntcred) указывает на структуру authsys parms, содержащую информацию о клиенте;

struct authsys parms {

u long aupjime: /* время создания информации */

char *aup machname; /* имя узла клиента */

uidj aup uid gidj aup gid u i nt aupj en

/* действующий идентификатор пользователя */ /* действующий идентификатор группы */ /* количество злементов в aup gids[] */

gidJ *aup g1dsl /* дополнительные идентификаторы группы */

Мы ползд1аем указатель на эту структуру и выводим имя узла клиента, его EUIDhEGID.

Запустив сервер и один экземпляр клиента, посмотрим на выводимый сервером текст:

Solaris X server

thread 1 started, arg = 44. auth = 1

AUTH SYS: host solaris.kohala.com. uid 765. gid 870

thread 1 done

Аутентификация Unix используется редко, поскольку ее легко обойти. Мы можем легко построить собственные пакеты RPC, содержащие аутентификаци-онную информацию в формате Unix, присвоив идентификатору пользователя и группы произвольные значения, и отправить их на сервер. Сервер никак не может проверить, те ли мы, кем представляемся.

ПРИМЕЧАНИЕ-

Вообще-то NFS по умолчанию использует именно аутентификацию Unix, но запросы обычно отсылаются ядром клиента NFS через зарезервированный порт (раздел 2.7 [24J). Некоторые серверы NFS настроены так, чтобы отвечать только на запросы, поступающие по зарезервированному порту. Если вы доверяете узлу клиента подключение к своим файловым системам, вы доверяете и его ядру в том, что оно правильно предоставляет информацию о своих пользователях. Если сервер не требует подключения по резервному порту, хакеры могут написать свою собственную программу, которая будет

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

Пакеты RPC - как запросы, так и ответы - содержат два поля, относящиеся к аутентификации: данные о пользователе и проверочную информацию (credentials, verifier). Примером такой структуры является документ с фотографией (паспорт, права и т. п.). Данные о пользователе соответствуют написанному в паспорте тексту (имя, адрес, дата рождения и т. п.), а проверочная информация - это фотография. Существуют разные формы проверочной информации: фотография в данном слзд1ае полезнее, чем, например, рост, вес и пол. Если документ не содержит проверочной информации (как, например, читательский билет в библиотеке), любой может воспользоваться им и сказать, что он его владелец.

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

I* AUTH SHORT - альтернативная форма аутентификации Unix, отправляемая сервером в поле ver1 tier в ответ на запрос клиента. Она содержит меньщее количество информации, чем в режиме аутентификации Unix, и клиент может отсылать ее серверу при последующих запросах. Используется для уменьщения количества передаваемой по сети информации.

ш AUTH DES - аббревиатура DES означает Data Encryption Standard (стандарт шифрования данных). Эта форма аутентификации основана на использовании криптографии с секретным и открытым ключом. Эта схема также называется защищенным RPC (secure RPC), а если она используется в качестве основы для построения NFS, то такая NFS также называется защищенной.

и AUTH KERB - эта схема основана на стандарте Kerberos института MIT.

В главе 19 книги [5] подробно рассказывается о двух последних формах аутентификации, включая их настройку и использование.

16.5. Тайм-аут и повторная передача

Рассмотрим стратегию обработки тайм-аутов и повторной передачи, используемую в средствах Sun RPC. Существуют два значения тайм-аутов:

1. Общий тайм-аут определяет время ожидания ответа сервера гслиентом. Это значение используется протоколами TCP и UDP.

2. Тайм-аут повтора используется только UDP и определяет время ожидания между повторами запросов клиента, если ответ от сервера не приходит.

Для протокола TCP необходимость во введении тайм-аута повтора отсутствует, поскольку этот протокол является надежным. Если сервер не ползд1ает запроса от клиента, время ожидания по протоколу TCP со стороны клиента закончится