
Prev		Next

2. Термины и соглашения

2.1. Определения

Терминология, используемая в PAM, достаточно запутана. Ни оригинальная работа Samar и Lai, ни спецификация XSSO не делают никаких попыток формально определить термины для различных объектов и участвующих в PAM сторон, а термины, которые они используют (но не определяют) иногда неверны и неоднозначны. Первой попыткой создать недвусмысленную и согласованную терминологию была работа, которую написал Andrew G. Morgan (автор Linux-PAM) в 1999 году. Хотя выбор терминологии, которую сделал Морган, был гигантским скачком вперед, это, по мнению автора данной статьи, не означает ее правильность. Далее делается попытка, в значительной степени на основе работы Моргана, дать точные и недвусмысленные определения терминов для всех участников и объектов PAM.

учётная запись (account): Набор полномочий, которые аппликант запрашивает от арбитратора.
аппликант (applicant): Пользователь или объект, запрашивающие аутентификацию.
арбитратор (arbitrator): Пользователь или объект, имеющий привилегии, достаточные для проверки полномочий аппликанта и права подтвердить или отклонить запрос.
цепочка (chain): Последовательность модулей, которые будут вызваны в ответ на запрос PAM. В цепочку включена информация о последовательности вызовов модулей, аргументах, которые нужно им передать, и о том, как интерпретировать результаты.
клиент (client): Приложение, отвечающее за инициирование запроса на аутентификацию от имени аппликанта и получающее от него необходимую для аутентификации информацию.
подсистема (facility): Одна из четырех основных групп функциональности, которые дает PAM: аутентификация, управление учетными записями, управление сеансом и обновление ключом аутентификации.
модуль (module): Набор из одной или большего количества связанных функций, реализующих определенную подсистему аутентификации, собранный в один (обычно динамически загружаемый) двоичный файл, идентифицируемый по имени.
политика (policy): Полный набор конфигурационных деклараций, описывающих, как обрабатывать запросы PAM к определенной услуге. Политика обычно состоит из четырех цепочек, по одной для каждой подсистемы, хотя некоторые службы используют не все четыре подсистемы.
сервер (server): Приложение, выступающее от имени арбитратора для общения с клиентом, запрашивания аутентификационной информации, проверки полномочий аппликанта и подтверждающее или отклоняющее запрос.
сервис (service): Класс серверов, предоставляющих похожую или связанную функциональность, и требующую подобную аутентификацию. Политики PAM задаются на основе сервисов, так что ко всем серверам, объявляющим одно и тоже имя сервиса, будет применяться одна и та же политика.
сеанс (session): Контекст, в котором сервис оказывается аппликанту сервером. Одна из четырех подсистем PAM, управление сеансом, касается исключительно настройке и очистке этого контекста.
ключ (token): Блок информации, связанный с учётной записью, например, пароль или ключевая фраза, которую аппликант должен предоставить для своей идентификации.
транзакция (transaction): Последовательность запросов от одного и того же аппликанта к одному и тому же экземпляру того же самого сервера, начиная с аутентификации и установления сеанса и заканчивая закрытием сеанса.

2.2. Примеры использования

Этот раздел предназначен для иллюстрации значений некоторых терминов, определенных выше, при помощи простых примеров.

2.2.1. Объединенные клиент и сервер

В этом простом примере показывается пользователь alice, выполняющий команду su(1) для того, чтобы стать пользователем root.

% whoami
alice
% ls -l `which su`
-r-sr-xr-x  1 root  wheel  10744 Dec  6 19:06 /usr/bin/su
% su -
Password: xi3kiune
# whoami
root

Аппликантом является alice.
Учетной записью является root.
Процесс su(1) является как клиентом, так и сервером.
Аутентификационным ключом является xi3kiune.
Арбитратором выступает root, и именно поэтому у команды su(1) выставлен бит выполнения с правами root.

2.2.2. Клиент и сервер разделены

В примере ниже рассматривается пользователь eve, пытающийся установить ssh(1)-соединение с login.example.com, и успешно входя как пользователь bob. Боб должен был выбрать пароль получше!

% whoami
eve
% ssh bob@login.example.com
bob@login.example.com's password: god
Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.  All rights reserved.
FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001

Welcome to FreeBSD!
%

Аппликантом является eve.
Клиентом является процесс ssh(1) пользователя Eve.
Сервером является процесс sshd(8) на машине login.example.com
Учетной записью является bob.
Ключом аутентификации является god.
Хотя этого не видно в примере, но арбитратором является root.

2.2.3. Пример политики

Следующее является политикой, используемой во FreeBSD по умолчанию для sshd:

sshd   auth            required        pam_nologin.so  no_warn
sshd   auth            required        pam_unix.so     no_warn try_first_pass
sshd   account         required        pam_login_access.so
sshd   account         required        pam_unix.so
sshd   session         required        pam_lastlog.so  no_fail
sshd   password        required        pam_permit.so

Эта политика применяется к службе sshd (что не обязательно ограничено сервером sshd(8)).
auth, account, session и password являются подсистемами.
pam_nologin.so, pam_unix.so, pam_login_access.so, pam_lastlog.so и pam_permit.so являются модулями. Из этого примера видно, что pam_unix.so реализует по крайней мере две подсистемы (аутентификацию и управление учётными записями).

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.