---
title: Подключаемые Модули Аутентификации (PAM)
authors:
  - author: Dag-Erling Smørgrav
releaseinfo: "$FreeBSD$" 
trademarks: ["pam", "freebsd", "linux", "opengroup", "sun", "general"]
---

= Подключаемые Модули Аутентификации (PAM)
:doctype: article
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:
:toc-title: Содержание
:part-signifier: Часть
:chapter-signifier: Глава
:appendix-caption: Приложение
:table-caption: Таблица
:figure-caption: Рисунок
:example-caption: Пример

[.abstract-title]
Abstract

В этой статье описываются принципы и механизмы, лежащие в основе библиотеки Подключаемых Модулей Аутентификации (PAM - Pluggable Authentication Modules), и рассказывается, как настроить PAM, как интегрировать PAM в приложения и как создавать модули PAM.

'''

toc::[]

[[pam-intro]]
== Введение

Библиотека Pluggable Authentication Modules (PAM) является обобщённым API для служб, связанных с аутентификацией, которые позволяют системному администратору добавлять новые методы аутентификации простой установкой новых модулей PAM, и изменять политику аутентификации посредством редактирования конфигурационных файлов.

PAM описали и разработали Vipin Samar и Charlie Lai из Sun Microsystems в 1995 году, с тех он сильно не менялся. В 1997 году Open Group опубликовала предварительные спецификации на X/Open Single Sign-on (XSSO), что стандартизовало API для PAM и добавило расширения для одноразовой (или достаточно интегрированной) подписи. На момент написания этого документа эта спецификация ещё не была принята за стандарт.

Хотя эта статья посвящена в основном FreeBSD 5.x, в которой используется OpenPAM, она подойдёт для FreeBSD 4.x, использующей Linux-PAM, и других операционных систем, таких, как Linux и Solaris(TM).

[[pam-terms]]
== Термины и соглашения

[[pam-definitions]]
== Определения

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

[.glosslist]
учётная запись (account)::
  Набор полномочий, которые аппликант запрашивает от арбитратора.

аппликант (applicant)::
  Пользователь или объект, запрашивающие аутентификацию.

арбитратор (arbitrator)::
  Пользователь или объект, имеющий привилегии, достаточные для проверки полномочий аппликанта и права подтвердить или отклонить запрос.

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

клиент (client)::
  Приложение, отвечающее за инициирование запроса на аутентификацию от имени аппликанта и получающее от него необходимую для аутентификации информацию.

подсистема (facility)::
  Одна из четырех основных групп функциональности, которые дает PAM: аутентификация, управление учетными записями, управление сеансом и обновление ключом аутентификации.

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

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

сервер (server)::
  Приложение, выступающее от имени арбитратора для общения с клиентом, запрашивания аутентификационной информации, проверки полномочий аппликанта и подтверждающее или отклоняющее запрос.

сервис (service)::
  Класс серверов, предоставляющих похожую или связанную функциональность, и требующую подобную аутентификацию. Политики PAM задаются на основе сервисов, так что ко всем серверам, объявляющим одно и тоже имя сервиса, будет применяться одна и та же политика.

сеанс (session)::
  Контекст, в котором сервис оказывается аппликанту сервером. Одна из четырех подсистем PAM, управление сеансом, касается исключительно настройке и очистке этого контекста.

ключ (token)::
  Блок информации, связанный с учётной записью, например, пароль или ключевая фраза, которую аппликант должен предоставить для своей идентификации.

транзакция (transaction)::
  Последовательность запросов от одного и того же аппликанта к одному и тому же экземпляру того же самого сервера, начиная с аутентификации и установления сеанса и заканчивая закрытием сеанса.

[[pam-usage-examples]]
== Примеры использования

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

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

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

[source,bash]
....
% 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`.
* Процесс man:su[1] является как клиентом, так и сервером.
* Аутентификационным ключом является `xi3kiune`.
* Арбитратором выступает `root`, и именно поэтому у команды man:su[1] выставлен бит выполнения с правами `root`.

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

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

[source,bash]
....
% 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`.
* Клиентом является процесс man:ssh[1] пользователя Eve.
* Сервером является процесс man:sshd[8] на машине `login.example.com`
* Учетной записью является `bob`.
* Ключом аутентификации является `god`.
* Хотя этого не видно в примере, но арбитратором является `root`.

== Пример политики

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

[.programlisting]
....
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` (что не обязательно ограничено сервером man:sshd[8]).
* `auth`, `account`, `session` и `password` являются подсистемами.
* [.filename]#pam_nologin.so#, [.filename]#pam_unix.so#, [.filename]#pam_login_access.so#, [.filename]#pam_lastlog.so# и [.filename]#pam_permit.so# являются модулями. Из этого примера видно, что [.filename]#pam_unix.so# реализует по крайней мере две подсистемы (аутентификацию и управление учётными записями).

[[pam-essentials]]
== Основы PAM

[[pam-facilities-primitives]]
== Подсистемы и примитивы

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

`auth`::
_Аутентификация._ Эта подсистема, собственно говоря, реализует аутентификацию аппликанта и выяснение полномочий учётной записи. Она предоставляет два примитива:

** Функция man:pam_authenticate[3] аутентифицирует аппликанта, обычно запрашивая аутентификационный ключ и сравнивая его со значением, хранящимся в базе данных или получаемым от сервера аутентификации.
** Функция man:pam_setcred[3] устанавливает полномочия учётной записи, такие, как идентификатор пользователя, членство в группах и ограничения на использование ресурсов.

`account`::
_Управление учётной записью._ Эта подсистема обрабатывает вопросы доступности учетной записи, не связанные с аутентификацией, такие, как ограничения в доступе на основе времени суток или загрузки сервера. Он предоставляет единственный примитив:

** Функция man:pam_acct_mgmt[3] проверяет, доступна ли запрашиваемая учётная запись.

`session`::
_Управление сеансом._ Эта подсистема отрабатывает задачи, связанные с установлением и закрытием сеанса, такие, как учет входов пользователей. Она предоставляет два примитива:

** Функция man:pam_open_session[3] выполняет действия, связанные с установлением сеанса: добавление записей в базы данных [.filename]#utmp# и [.filename]#wtmp#, запуск агента SSH и так далее.
** Функция man:pam_close_session[3] выполняет действия, связанные с закрытием сеанса: добавление записей в базы данных [.filename]#utmp# и [.filename]#wtmp#, завершение работы агента SSH и так далее.

`password`::
_Управление паролем._ Эта подсистема используется для изменения ключа аутентификации, связанного с учетной записью, по причине истечения его срока действия или желания пользователя изменить его. Она предоставляет единственный примитив:

** Функция man:pam_chauthtok[3] изменяет ключ аутентификации, опционально проверяя, что он труден для подбора, не использовался ранее и так далее.

[[pam-modules]]
== Модули

Модули являются центральной концепцией в PAM; в конце концов, им соответствует буква "M" в сокращении "PAM". Модуль PAM представляет собой самодостаточный кусок программного кода, который реализует примитивы одной или большего количества подсистем одного конкретного механизма; к возможным механизмам для подсистемы аутентификации, к примеру, относятся базы данных паролей UNIX(R), системы NIS, LDAP или Radius.

[[pam-module-naming]]
== Именование модулей

Во FreeBSD каждый механизм реализуется в отдельном модуле с именем `pam_mechanism.so` (например, `pam_unix.so` для механизма UNIX(R).) В других реализациях иногда отдельные модули используются для разных подсистем, и в их имя включается, кроме названия механизма, и имя подсистемы. К примеру, в Solaris(TM) имеется модуль `pam_dial_auth.so.1`, который часто используется для аутентификации пользователей, работающих по коммутируемым каналам связи.

[[pam-module-versioning]]
== Версии модулей

Изначальная реализация PAM во FreeBSD, которая была основана на Linux-PAM, не использовала номера версий для модулей PAM. Это будет приводить к проблемам при работе унаследованных приложений, которые могут быть скомпонованы со старыми версиями системных библиотек, так как способа подгрузить соответствующую версию требуемых модулей нет.

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

Хотя модули PAM в Solaris(TM) имеют номер версии, по-настоящему номер версии в них не отслеживается, потому что номер является частью имени и должен включаться в конфигурацию.

[[pam-chains-policies]]
== Цепочки и политики

Когда сервер инициирует PAM-транзакцию, библиотека PAM пытается загрузить политику для службы, указанной при вызове функции man:pam_start[3]. Политика определяет, как должны обрабатываться запросы на аутентификацию, и задаётся в конфигурационном файле. Это составляет другую основополагающую концепцию PAM: возможность администратору настраивать политику безопасности системы (в самом широком её понимании) простым редактированием текстового файла.

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

Понимание смысла управляющего флага необходимо для понимания конфигурационных файлов PAM. Существуют четыре различных управляющих флага:

`binding`::
Если модуль отработал успешно, и ни один из предыдущих модулей в цепочке не сработал отрицательно, то цепочка прерывается, а запрос подтверждается. Если же модуль отработает неудачно, то выполняется оставшаяся часть цепочки, однако запрос отвергается.
+
Этот управляющий флаг был добавлен компанией Sun в Solaris(TM) 9 (SunOS(TM) 5.9), и поддерживается в OpenPAM.
`required`::
Если модуль возвратил положительный ответ, выполняется оставшаяся часть цепочки, запрос удовлетворяется, если никакой другой модуль не отработает отрицательно. Если же модуль возвратит отрицательный ответ, остаток цепочки тоже отрабатывается, но запрос отвергается.
`requisite`::
Если модуль возвращает положительный ответ, выполняется оставшаяся часть цепочки, запрос удовлетворяется, если никакой другой модуль не отработает отрицательно. Если же модуль отрабатывает отрицательно, то отработка цепочки немедленно прекращается, а запрос отвергается.

`sufficient`::
Если модуль возвратит положительный ответ, и ни один из предыдущих модулей в цепочке на отработал отрицательно, то отработка цепочки немедленно прекращается, а запрос удовлетворяется. Если модуль отработал отрицательно, то результат игнорируется и цепочка отрабатывается дальше.
+
Так как семантика этого флага может оказаться запутанной, особенно при его использовании с последним модулем в цепочке, рекомендуется вместо него использовать управляющий флаг `binding`, если реализация его поддерживает.
`optional`::
Модуль отрабатывается, но результат выполнения игнорируется. Если все модули в цепочке помечены как `optional`, то удовлетворяться будут все запросы.
Когда сервер вызывает один из шести PAM-примитивов, PAM запрашивает цепочку подсистемы, к которой принадлежит примитив, и запускает каждый модуль, перечисленный в цепочке в порядке их перечисления, пока список не будет исчерпан либо не будет определено, что дальнейшей обработки не нужно (по причине достижение модуля, вернувшего положительный ответ при условии `binding` или `sufficient`, либо отрицательный с условием `requisite`). Запрос подтверждается, если только был вызван по крайней мере один модуль, и все неопциональные модули вернули положительный ответ.

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

[[pam-transactions]]
== Транзакции

Жизненный цикл типичной PAM-транзакции описан ниже. Заметьте, что в случае, если любой из перечисленных шагов оканчивается неудачно, сервер должен выдать клиенту соответствующее сообщение об ошибке и прервать транзакцию.

. Если это необходимо, сервер получает полномочия арбитратора через независимый от PAM механизм-чаще всего по факту запуска пользователем `root` или с установленным setuid-битом `root`.
. Сервер вызывает функцию man:pam_start[3] для инициализации библиотеки PAM и задания имени сервиса и целевой учётной записи, а также регистрации подходящего способа общения.
. Сервер получает различную информацию, относящуюся к транзакции (такую, как имя пользователя аппликанта и имя хоста, на котором запущен клиент), и отправляет её в PAM при помощи функции man:pam_set_item[3].
. Сервер вызывает функцию man:pam_authenticate[3] для аутентификации аппликанта.
. Сервер вызывает функцию man:pam_acct_mgmt[3] для проверки того, что запрошенная учётная запись доступна и корректна. Если пароль верен, но его срок истёк, man:pam_acct_mgmt[3] возвратит результат `PAM_NEW_AUTHTOK_REQD`, а не `PAM_SUCCESS`.
. Если на предыдущем шаге был получен результат `PAM_NEW_AUTHTOK_REQD`, то сервер вызывает функцию man:pam_chauthtok[3] для того, чтобы вынудить клиента изменить ключ аутентификации для запрошенной учётной записи.
. Теперь, когда аппликант полностью аутентифицирован, сервер вызывает функцию man:pam_setcred[3] для получения полномочий запрошенной учётной записи. Сделать это возможно, потому что он работает как арбитратор, и оставляет за собой полномочия арбитратора.
. После получения необходимых полномочий, сервер вызывает функцию man:pam_open_session[3] для установления сеанса.
. Теперь сервер выполняет тот сервис, который затребовал клиент-например, предоставляет аппликанту оболочку.
. После того, как сервер закончил обслуживание клиента, он вызывает функцию man:pam_close_session[3] для закрытия сеанса.
. Наконец, сервер вызывает функцию man:pam_end[3] для оповещения библиотеки PAM о том, что работа с ней завершена и какие-либо выделенные в течение сеанса ресурсы можно освободить.

[[pam-config]]
== Настройка PAM

[[pam-config-file]]
== Файлы политик PAM

[[pam-config-pam.conf]]
== Файл [.filename]#/etc/pam.conf#

Традиционно файлом политик PAM является [.filename]#/etc/pam.conf#. Он содержит все политики PAM для вашей системы. Каждая строка файла описывает один шаг в цепочке, как показано ниже:

[.programlisting]
....
login   auth    required        pam_nologin.so  no_warn
....

Поля следуют в таком порядке: имя службы, имя подсистемы, управляющий флаг, имя модуля и параметры модуля. Любые дополнительные поля интерпретируются как дополнительные параметры модуля.

Для каждой пары сервис/подсистема составляется отдельная цепочка, и тогда получается, что, хотя порядок следования строк для одной и той же услуги и подсистемы является значимым, порядок перечисления отдельных сервисов не значим. В примерах из оригинальной работы по PAM строки конфигурации сгруппированы по подсистемам, в поставляемом с Solaris(TM) файле [.filename]#pam.conf# именно так и сделано, но в стандартном конфигурационном файле из поставки FreeBSD строки настроек сгруппированы по сервисам. Подходит любой из этих способов; они имеют один и тот же смысл.

[[pam-config-pam.d]]
== Каталог [.filename]#/etc/pam.d#

OpenPAM и Linux-PAM поддерживают альтернативный механизм настройки, который для FreeBSD является предпочтительным. В этой схеме каждая политика содержится в отдельном файле с именем, соответствующем сервису, к которому она применяется. Эти файлы размещаются в каталоге [.filename]#/etc/pam.d/#.

Такие файлы политик, ориентированные на сервисы, имеют только четыре поля, вместо пяти полей в файле [.filename]#pam.conf#: поле имени сервиса опущено. Таким образом, вместо примера строки файла [.filename]#pam.conf# из предыдущего раздела получится следующая строка в файле [.filename]#/etc/pam.d/login#:

[.programlisting]
....
auth    required        pam_nologin.so  no_warn
....

Как следствие такого упрощённого синтаксиса, возможно использование одних и тех же политик для нескольких сервисов, связывая каждое имя сервиса с тем же самым файлом политик. К примеру, для использования той же самой политики для сервисов `su` и `sudo`, можно сделать следующее:

[source,bash]
....
# cd /etc/pam.d
# ln -s su sudo
....

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

Так как политика каждого сервиса хранится в отдельном файле, то механизм [.filename]#pam.d# делает установку дополнительных политик для программных пакетов сторонних разработчиков очень лёгкой задачей.

[[pam-config-file-order]]
== Порядок поиска политик

Как вы видели выше, политики PAM могут находиться в нескольких местах. Что будет, если политики для одного и того же сервиса имеются в разных местах?

Необходимо осознать, что система конфигурации PAM ориентирована на цепочки.

[[pam-config-breakdown]]
== Структура строки настройки

Как это объяснено в <<pam-config-file>>, каждая строка файла [.filename]#/etc/pam.conf# состоит из четырёх или большего количества полей: имени сервиса, имени подсистемы, управляющего флага, имени модуля и дополнительных параметров модуля, которые могут отсутствовать.

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

Заметьте, что если вы используете [.filename]#/etc/pam.d/# вместо [.filename]#/etc/pam.conf#, то имя сервиса задается именем файла политики, и опускается из строк настройки, которые в таком случае начинаются с названия подсистемы.

Имя подсистемы представляет собой одно из четырёх ключевых слов, описанных в <<pam-facilities-primitives>>.

Точно также управляющий флаг является одним из четырёх ключевых слов, описанных в <<pam-chains-policies>>, в котором рассказано, как интерпретировать возвращаемый из модуля код. В Linux-PAM поддерживается альтернативный синтаксис, который позволяет указать действие, связанной с каждый возможным кодом возврата, но этого следует избегать, так как он не является стандартным и тесно связан со способом диспетчеризации вызовов сервисов в Linux-PAM (а он значительно отличается от способа взаимодействия в Solaris(TM) и OpenPAM). Не вызывает удивления тот факт, что в OpenPAM этот синтаксис не поддерживается.

[[pam-policies]]
== Политики

Для корректной настройки PAM необходимо понимать, как происходит интерпретация политик.

В момент, когда приложение вызывает функцию man:pam_start[3], библиотека PAM загружает политику для указанного сервиса и выстраивает четыре цепочки модулей (по одной для каждой подсистемы). Если одна или большее количество этих цепочек являются пустыми, то будут выполняться подстановки соответствующих цепочек из политики для сервиса `other`.

Когда затем приложение вызывает одну из шести примитивов PAM, библиотека PAM выделяет из цепочки нужную подсистему и вызывает функцию, соответствующую сервису, в каждом модуле, перечисленном в цепочке, в том порядке, в каком они перечислены в конфигурации. После каждого обращения к функции сервиса, тип модуля и возвращённый из этой функции код результата выполнения используются для того, что делать дальше. За некоторыми исключениями, которые будут описаны ниже, применяется такая таблица:

.Сводная таблица отработки цепочек PAM
[cols="1,1,1,1", options="header"]
|===
| 
| PAM_SUCCESS
| PAM_IGNORE
| other

|binding
|if (!fail) break;
|-
|fail = true;

|required
|-
|-
|fail = true;

|requisite
|-
|-
|fail = true; break;

|sufficient
|if (!fail) break;
|-
|-

|optional
|-
|-
|-
|===

Если переменная `fail` принимает истинное значение в конце отработки цепочки, или когда достигнут "break", диспетчер возвращает код ошибки, возвращённый первым модулем, отработавшим неудачно. В противном случае возвращается `PAM_SUCCESS`.

Первым исключением является то, что код ошибки `PAM_NEW_AUTHTOK_REQD` интерпретируется как успешный результат, кроме случая, когда модуль отработал успешно, и по крайней мере один модуль возвратил `PAM_NEW_AUTHTOK_REQD`, тогда диспетчер возвратит результат `PAM_NEW_AUTHTOK_REQD`.

Вторым исключением является то, что man:pam_setcred[3] считает, что модули `binding` и `sufficient` являются равнозначными `required`.

Третьим и последним исключением является то, что функция man:pam_chauthtok[3] отрабатывает полную цепочку дважды (один раз для предварительных проверок, и ещё раз для реального задания пароля), и на подготовительной фазе она считает, что модули `binding` и `sufficient` являются равнозначными `required`.

[[pam-freebsd-modules]]
== Модули PAM во FreeBSD

[[pam-modules-deny]]
=== man:pam_deny[8]

Модуль man:pam_deny[8] является одним из простейших доступных модулей; на любой запрос он возвращает результат `PAM_AUTH_ERR`. Он полезен для быстрого отключения сервиса (добавьте его на верх каждой цепочки) или завершения цепочек модулей `sufficient`.

[[pam-modules-echo]]
=== man:pam_echo[8]

Модуль man:pam_echo[8] просто передаёт свои параметры в функцию взаимодействия как сообщение `PAM_TEXT_INFO`. В основном полезна для отладки, но также может использоваться для вывода сообщений, таких как "Unauthorized access will be prosecuted" до запуска процедуры аутентификации.

[[pam-modules-exec]]
=== man:pam_exec[8]

Модуль man:pam_exec[8] воспринимает первый переданный ему параметр как имя программы для выполнения, а остальные аргументы передаются этой программе в качестве параметров командной строки. Одним из возможных применений является его использование для запуска в момент регистрации в системе программы монтирования домашнего каталога пользователя.

[[pam-modules-ftpusers]]
=== man:pam_ftpusers[8]

Модуль man:pam_ftpusers[8]

[[pam-modules-group]]
=== man:pam_group[8]

Модуль man:pam_group[8] принимает или отвергает аппликантов в зависимости от их членства в определённой файловой группе (обычно `wheel` для man:su[1]). В первую очередь предназначен для сохранения традиционного поведения утилиты BSD man:su[1], хотя имеет и много других применений, таких как отключение определённых групп пользователей от некоторого сервиса.

[[pam-modules-guest]]
=== man:pam_guest[8]

Модуль man:pam_guest[8] позволяет осуществлять гостевые входы с использованием фиксированных имён входа в систему. На пароль могут накладываться различные ограничения, однако действием по умолчанию является ввод любого пароля при использовании имени, соответствующего гостевому входу. Модуль man:pam_guest[8] можно легко использовать для реализации анонимных входов на FTP.

[[pam-modules-krb5]]
=== man:pam_krb5[8]

Модуль man:pam_krb5[8]

[[pam-modules-ksu]]
=== man:pam_ksu[8]

Модуль man:pam_ksu[8]

[[pam-modules-lastlog]]
=== man:pam_lastlog[8]

Модуль man:pam_lastlog[8]

[[pam-modules-login-access]]
=== man:pam_login_access[8]

Модуль man:pam_login_access[8] предоставляет реализацию примитива для управления учётными записями, который вводит в действие ограничения на вход, задаваемые в таблице man:login.access[5].

[[pam-modules-nologin]]
=== man:pam_nologin[8]

Модуль man:pam_nologin[8] отвергает любые входы не пользователем root, если существует файл [.filename]#/var/run/nologin#. Обычно этот файл создаётся утилитой man:shutdown[8], когда до запланированного завершения работы системы остаётся менее пяти минут.

[[pam-modules-opie]]
=== man:pam_opie[8]

Модуль man:pam_opie[8] реализует метод аутентификации man:opie[4]. Система man:opie[4] является механизмом работы по схеме запрос-ответ, при котором ответ на каждый запрос является прямой функцией от запроса и ключевой фразы, так что ответ может быть легко и "вовремя" вычислен любым, знающим ключевую фразу, что избавляет от необходимости передавать пароль. Кроме того, так как в man:opie[4] никогда повторно не используется запрос, ответ на который был корректно получен, эта схема является устойчивой к атакам, основанным на повторе действий.

[[pam-modules-opieaccess]]
=== man:pam_opieaccess[8]

Модуль man:pam_opieaccess[8] дополняет модуль man:pam_opie[8]. Его работа заключается в выполнении ограничений, задаваемых файлом man:opieaccess[5], который определяет условия, при которых пользователь, нормально прошедший аутентификацию посредством man:opie[4], может использовать альтернативные методы. Чаще всего он используется для запрета использования аутентификации на основе паролей с непроверенных хостов.

Для эффективности модуль man:pam_opieaccess[8] должен быть определён в цепочке `auth` как `requisite` сразу же после записи `sufficient` для man:pam_opie[8], но перед любыми другими модулями.

[[pam-modules-passwdqc]]
=== man:pam_passwdqc[8]

Модуль man:pam_passwdqc[8]

[[pam-modules-permit]]
=== man:pam_permit[8]

Модуль man:pam_permit[8] является одним из самых простым из имеющихся; на любой запрос он отвечает `PAM_SUCCESS`. Он полезен в качестве замены пустого места для сервисов, когда одна или большее количество цепочек в противном случае останутся пустыми.

[[pam-modules-radius]]
=== man:pam_radius[8]

Модуль man:pam_radius[8]

[[pam-modules-rhosts]]
=== man:pam_rhosts[8]

Модуль man:pam_rhosts[8]

[[pam-modules-rootok]]
=== man:pam_rootok[8]

Модуль man:pam_rootok[8] возвращает положительный результат в том и только в том случае, если реальный id пользователя процесса, его вызвавшего (предполагается, что его запускает аппликант) равен 0. Это полезно для несетевых сервисов, таких как man:su[1] или man:passwd[1], к которым пользователь `root` должен иметь автоматический доступ.

[[pam-modules-securetty]]
=== man:pam_securetty[8]

Модуль man:pam_securetty[8]

[[pam-modules-self]]
=== man:pam_self[8]

Модуль man:pam_self[8] возвращает положительный результат тогда и только тогда, когда имена аппликанта соответствуют целевой учётной записи. Больше всего это пригодится в несетевых сервисах, таких как man:su[1], в которых идентификация аппликанта может быть с лёгкостью проверена.

[[pam-modules-ssh]]
=== man:pam_ssh[8]

Модуль man:pam_ssh[8] предоставляет как сервис аутентификации, так и сеанса. Сервис аутентификации позволяет пользователям, имеющим секретные ключи SSH, защищённые паролями, в своих каталогах [.filename]#~/.ssh#, аутентифицироваться посредством этих паролей. Сеансовый сервис запускает man:ssh-agent[1] и загружает ключи, которые были расшифрованы на фазе аутентификации. Такая возможность, в частности, полезна для локальных входов в систему, как в систему X (посредством man:xdm[1] или другого X-менеджера входов, умеющего работать с PAM), так и на консоль.

[[pam-modules-tacplus]]
=== man:pam_tacplus[8]

Модуль man:pam_tacplus[8]

[[pam-modules-unix]]
=== man:pam_unix[8]

Модуль man:pam_unix[8] реализует традиционную аутентификацию UNIX(R) на основе паролей, использующую функцию man:getpwnam[3] для получения пароля целевой учётной записи и сравнивающую её с тем, что представил аппликант. Он также предоставляет средства управления учётными записями (отслеживая время действия учётной записи и пароля) и смены паролей. Наверное, это самый полезный модуль, так как подавляющее большинство администраторов хотят сохранить исторически сложившееся поведение по крайней мере некоторых сервисов.

[[pam-appl-prog]]
== Программирование приложений с PAM

Этот раздел ещё не написан.

[[pam-module-prog]]
== Программирование модуля PAM

Этот раздел ещё не написан.

:sectnums!:

[appendix]
[[pam-sample-appl]]
== Пример PAM-приложения

Далее следует минимальная реализация программы man:su[1] с использованием PAM. Заметьте, что в ней используется специфичная для OpenPAM функция взаимодействия man:openpam_ttyconv[3], объявление которой расположено в файле [.filename]#security/openpam.h#. Если вы собираетесь строить это приложение в системе с другой библиотекой PAM, вам необходимо будет создать собственную функцию взаимодействия. Надёжную функцию взаимодействия неожиданно трудно написать; та, что находится в <<pam-sample-conv>>, хороша в качестве отправной точки, но в реальных приложениях использоваться не может.

[.programlisting]
....
include::static/source/articles/pam/su.c[]
....

:sectnums!:

[appendix]
[[pam-sample-module]]
== Пример PAM-модуля

Далее приведена минимальная реализация man:pam_unix[8], предоставляющая только сервисы аутентификации. Она должна строиться и работать с большинством из реализаций PAM, но использует возможности расширений OpenPAM, если они присутствуют: отметьте использование функции man:pam_get_authtok[3], которая кардинально упрощает организацию ввода пароля пользователем.

[.programlisting]
....
include::static/source/articles/pam/pam_unix.c[]
....

:sectnums!:

[appendix]
[[pam-sample-conv]]
== Пример функции взаимодействия PAM

Функция взаимодействия, приводимая ниже, является значительно упрощённой версией функции man:openpam_ttyconv[3] из OpenPAM. Она полнофункциональна, и должна послужить источником идей о том, как должна себя вести функция взаимодействия, однако она слишком проста для реальных приложений. Даже если вы не используете OpenPAM, можете сгрузить исходный код и использовать man:openpam_ttyconv[3] в своих целях; мы надеемся, что она достаточно надёжна в качестве функции для взаимодействия с терминальными устройствами.

[.programlisting]
....
include::static/source/articles/pam/converse.c[]
....

:sectnums!:

[[pam-further]]
== Lectures complémentaires

=== Publications

_link:http://www.sun.com/software/solaris/pam/pam.external.pdf[Rendre les services de connexion indépendants des technologies d'authentification]_. Vipin Samar et Charlie Lai. Sun Microsystems.

_link:http://www.opengroup.org/pubs/catalog/p702.htm[X/Open Single Sign-on Preliminary Specification]_. The Open Group. 1-85912-144-6. June 1997.

_link:http://www.kernel.org/pub/linux/libs/pam/pre/doc/current-draft.txt[Pluggable Authentication Modules]_. Andrew G. Morgan. 1999-10-06.

=== Guides utilisateur

_link:http://www.sun.com/software/solaris/pam/pam.admin.pdf[Administration de PAM]_. Sun Microsystems.

=== Page internet liées

_link:http://openpam.sourceforge.net/[La page d'OpenPAM]_. Dag-Erling Smørgrav. ThinkSec AS.

_link:http://www.kernel.org/pub/linux/libs/pam/[La page de Linux-PAM]_. Andrew G. Morgan.

_link:http://wwws.sun.com/software/solaris/pam/[La page de Solaris PAM]_. Sun Microsystems.
