Традиционно файлом политик PAM является /etc/pam.conf. Он содержит все политики PAM для вашей системы. Каждая строка файла описывает один шаг в цепочке, как показано ниже:
login auth required pam_nologin.so no_warn
Поля следуют в таком порядке: имя службы, имя подсистемы, управляющий флаг, имя модуля и параметры модуля. Любые дополнительные поля интерпретируются как дополнительные параметры модуля.
Для каждой пары сервис/подсистема составляется отдельная цепочка, и тогда получается, что, хотя порядок следования строк для одной и той же услуги и подсистемы является значимым, порядок перечисления отдельных сервисов не значим. В примерах из оригинальной работы по PAM строки конфигурации сгруппированы по подсистемам, в поставляемом с Solaris™ файле pam.conf именно так и сделано, но в стандартном конфигурационном файле из поставки FreeBSD строки настроек сгруппированы по сервисам. Подходит любой из этих способов; они имеют один и тот же смысл.
OpenPAM и Linux-PAM поддерживают альтернативный механизм настройки, который для FreeBSD является предпочтительным. В этой схеме каждая политика содержится в отдельном файле с именем, соответствующем сервису, к которому она применяется. Эти файлы размещаются в каталоге /etc/pam.d/.
Такие файлы политик, ориентированные на сервисы, имеют только четыре поля, вместо пяти полей в файле pam.conf: поле имени сервиса опущено. Таким образом, вместо примера строки файла pam.conf из предыдущего раздела получится следующая строка в файле /etc/pam.d/login:
auth required pam_nologin.so no_warn
Как следствие такого упрощённого синтаксиса, возможно использование одних и тех же политик для нескольких сервисов, связывая каждое имя сервиса с тем же самым файлом политик. К примеру, для использования той же самой политики для сервисов su и sudo, можно сделать следующее:
# cd /etc/pam.d # ln -s su sudo
Это работает, потому что имя сервиса определяется именем файла, а не его указанием в файле политики, так что один и тот же файл может использоваться для нескольких сервисов с разными названиями.
Так как политика каждого сервиса хранится в отдельном файле, то механизм pam.d делает установку дополнительных политик для программных пакетов сторонних разработчиков очень лёгкой задачей.
Как вы видели выше, политики PAM могут находиться в нескольких местах. Что будет, если политики для одного и того же сервиса имеются в разных местах?
Необходимо осознать, что система конфигурации PAM ориентирована на цепочки.
Как это объяснено в разделе Файлы политик PAM, каждая строка файла /etc/pam.conf состоит из четырёх или большего количества полей: имени сервиса, имени подсистемы, управляющего флага, имени модуля и дополнительных параметров модуля, которые могут отсутствовать.
Имя сервиса обычно (хотя не всегда) является именем приложения, которое этот сервис обслуживает. Если вы не уверены, обратитесь к документации по конкретному приложению для определения используемого имени сервиса.
Заметьте, что если вы используете /etc/pam.d/ вместо /etc/pam.conf, то имя сервиса задается именем файла политики, и опускается из строк настройки, которые в таком случае начинаются с названия подсистемы.
Имя подсистемы представляет собой одно из четырёх ключевых слов, описанных в главе Подсистемы и примитивы.
Точно также управляющий флаг является одним из четырёх ключевых слов, описанных в разделе Цепочки и политики, в котором рассказано, как интерпретировать возвращаемый из модуля код. В Linux-PAM поддерживается альтернативный синтаксис, который позволяет указать действие, связанной с каждый возможным кодом возврата, но этого следует избегать, так как он не является стандартным и тесно связан со способом диспетчеризации вызовов сервисов в Linux-PAM (а он значительно отличается от способа взаимодействия в Solaris и OpenPAM). Не вызывает удивления тот факт, что в OpenPAM этот синтаксис не поддерживается.
Для корректной настройки PAM необходимо понимать, как происходит интерпретация политик.
В момент, когда приложение вызывает функцию pam_start(3), библиотека PAM загружает политику для указанного сервиса и выстраивает четыре цепочки модулей (по одной для каждой подсистемы). Если одна или большее количество этих цепочек являются пустыми, то будут выполняться подстановки соответствующих цепочек из политики для сервиса other.
Когда затем приложение вызывает одну из шести примитивов PAM, библиотека PAM выделяет из цепочки нужную подсистему и вызывает функцию, соответствующую сервису, в каждом модуле, перечисленном в цепочке, в том порядке, в каком они перечислены в конфигурации. После каждого обращения к функции сервиса, тип модуля и возвращённый из этой функции код результата выполнения используются для того, что делать дальше. За некоторыми исключениями, которые будут описаны ниже, применяется такая таблица:
Таблица 1. Сводная таблица отработки цепочек PAM
| 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.
Вторым исключением является то, что pam_setcred(3) считает, что модули binding и sufficient являются равнозначными required.
Третьим и последним исключением является то, что функция pam_chauthtok(3) отрабатывает полную цепочку дважды (один раз для предварительных проверок, и ещё раз для реального задания пароля), и на подготовительной фазе она считает, что модули binding и sufficient являются равнозначными required.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.