на главную | войти | регистрация | DMCA | контакты | справка | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


моя полка | жанры | рекомендуем | рейтинг книг | рейтинг авторов | впечатления | новое | форум | сборники | читалки | авторам | добавить




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

//sunrpc/square4/server.c

1  #include "unpipc.h"

2  #include "square.h"


3  bool_t

4  squareproc_2_svc(square_in *inp, square_out *outp, struct svc_req *rqstp)

5  {

6   printf("thread %Id started, arg = %ld, auth = %d\n",

7   pr_thread_id(NULL), inp->arg1, 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   printf("AUTH_SYS: host %s, uid %ld, gid %ld\n",

12    au->aup_machname, (long) au->aup_uid, (long) au->aup_gid);

13  }

14  sleep(5);

15  outp->res1 = inp->arg1 * inp->arg1;

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; /* номер версии */

 u_long rq_proc; /* номер процедуры */

 struct opaque_auth rq_cred:/* данные о клиенте */

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

 SVCXPRT *rq_xprt; /* транспортный дескриптор */

};


struct opaque_auth {

 enum_t oa_flavor; /* flavor: константа AUTH_xxx */

 caddr_t oa_base; /* адрес дополнительной аутентификационной информации */

 u_int oa_length; /* не должно превосходить MAX_AUTH_BYTES */

};

Поле rq_cred содержит неформатированную информацию о клиенте, а его поле oa_flavor содержит целое число, определяющее тип аутентификации. Термин «неформатированная» означает, что библиотека не обработала информацию, на которую указывает oa_base. Но если тип идентификации относится к одному из поддерживаемых библиотекой, то в готовой информации о клиенте, на которую указывает rq_clntcred, содержится некоторая структура, соответствующая данному типу аутентификации. Программа выводит тип аутентификации и прове-9_12 ряет, соответствует ли он AUTH_SYS.

Для аутентификации Unix указатель на готовую информацию (rq_clntcred) указывает на структуру authsys_parms, содержащую информацию о клиенте:

struct authsys_parms {

 u_long aup_time; /* время создания информации */

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

 uid_t aup_uid; /* действующий идентификатор пользователя */

 gid_t aup_gid; /* действующий идентификатор группы */

 u_int aup_len; /* количество элементов в aup_gids[] */

 gid_t *aup_gidsl; /* дополнительные идентификаторы группы */

};

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

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

solaris % 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 [24]). Некоторые серверы NFS настроены так, чтобы отвечать только на запросы, поступающие по зарезервированному порту. Если вы доверяете узлу клиента подключение к своим файловым системам, вы доверяете и его ядру в том, что оно правильно предоставляет информацию о своих пользователях. Если сервер не требует подключения по резервному порту, хакеры могут написать свою собственную программу, которая будет посылать запросы серверу NFS с произвольным идентификатором пользователя. Даже если сервер требует подключения по зарезервированному порту, а у вас есть своя система, в которой вы обладаете правами привилегированного пользователя, и вы можете подключиться к сети, вы сможете отправлять свои собственные запросы с произвольным содержимым на сервер NFS. 

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

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

AUTH_SHORT — альтернативная форма аутентификации Unix, отправляемая сервером в поле verifier в ответ на запрос клиента. Она содержит меньшее количество информации, чем в режиме аутентификации Unix, и клиент может отсылать ее серверу при последующих запросах. Используется для уменьшения количества передаваемой по сети информации.

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

AUTH_KERB — эта схема основана на стандарте Kerberos института MIT.

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


Листинг 16.7. Клиент, осуществляющий аутентификацию unix | UNIX: взаимодействие процессов | 16.5. Тайм-аут и повторная передача