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

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 реализует по крайней мере две подсистемы (аутентификацию и управление учётными записями).

Пред.   След.
Подключаемые Модули Аутентификации (PAM) Начало 3. Основы PAM

Этот, и другие документы, могут быть скачаны с https://download.freebsd.org/ftp/doc/.

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

По вопросам, связанным с этой документацией, пишите в рассылку <doc@FreeBSD.org>.