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

# 4. Настройка PAM

## 4.1. Файлы политик PAM

### 4.1.1. Файл `/etc/pam.conf`

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

    login   auth    required        pam_nologin.so  no_warn

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

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

### 4.1.2. Каталог `/etc/pam.d`

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` делает установку дополнительных политик для программных пакетов сторонних разработчиков очень лёгкой задачей.

### 4.1.3. Порядок поиска политик

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

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

## 4.2. Структура строки настройки

Как это объяснено в разделе Файлы политик PAM, каждая строка файла `/etc/pam.conf` состоит из четырёх или большего количества полей: имени сервиса, имени подсистемы, управляющего флага, имени модуля и дополнительных параметров модуля, которые могут отсутствовать.

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

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

Имя подсистемы представляет собой одно из четырёх ключевых слов, описанных в главе Подсистемы и примитивы.

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

## 4.3. Политики

Для корректной настройки 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`.

Пред. | Начало | След.
Основы PAM |  | Модули PAM во FreeBSD

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

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