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).
+Хотя эта статья посвящена в основном FreeBSD 5.x, в которой используется OpenPAM, она подойдёт для FreeBSD 4.x, использующей Linux-PAM, а также для других операционных систем, таких как Linux и Solaris(TM).
[[pam-terms]]
== Термины и соглашения
@@ -101,7 +101,7 @@
[[pam-definitions]]
=== Определения
-Терминология, используемая в PAM, достаточно запутана. Ни оригинальная работа Samar и Lai, ни спецификация XSSO не делают никаких попыток формально определить термины для различных объектов и участвующих в PAM сторон, а термины, которые они используют (но не определяют) иногда неверны и неоднозначны. Первой попыткой создать недвусмысленную и согласованную терминологию была работа, которую написал Andrew G. Morgan (автор Linux-PAM) в 1999 году. Хотя выбор терминологии, которую сделал Морган, был гигантским скачком вперед, это, по мнению автора данной статьи, не означает ее правильность. Далее делается попытка, в значительной степени на основе работы Моргана, дать точные и недвусмысленные определения терминов для всех участников и объектов PAM.
+Терминология, используемая в PAM, достаточно запутанна. Ни оригинальная работа Samar и Lai, ни спецификация XSSO не делают никаких попыток формально определить термины для различных объектов и участвующих в PAM сторон, а термины, которые они используют (но не определяют) иногда неверны и неоднозначны. Первой попыткой создать однозначную и непротиворечивую терминологию была работа, которую написал Andrew G. Morgan (автор Linux-PAM) в 1999 году. Хотя выбор терминологии, которую сделал Морган, был гигантским скачком вперёд, это, по мнению автора данной статьи, не означает её правильность. Далее делается попытка, в значительной степени на основе работы Моргана, дать точные и недвусмысленные определения терминов для всех участников и объектов PAM.
учётная запись (account)::
Набор полномочий, которые аппликант запрашивает от арбитратора.
@@ -119,13 +119,13 @@
Приложение, отвечающее за инициирование запроса на аутентификацию от имени аппликанта и получающее от него необходимую для аутентификации информацию.
подсистема (facility)::
-Одна из четырех основных групп функциональности, которые дает PAM: аутентификация, управление учетными записями, управление сеансом и обновление ключом аутентификации.
+Одна из четырёх основных групп функциональности, которые даёт PAM: аутентификация, управление учётными записями, управление сеансом и обновление ключом аутентификации.
модуль (module)::
-Набор из одной или большего количества связанных функций, реализующих определенную подсистему аутентификации, собранный в один (обычно динамически загружаемый) двоичный файл, идентифицируемый по имени.
+Набор из одной или большего количества связанных функций, реализующих определённую подсистему аутентификации, собранный в один (обычно динамически загружаемый) двоичный файл, идентифицируемый по имени.
политика (policy)::
-Полный набор конфигурационных деклараций, описывающих, как обрабатывать запросы PAM к определенной услуге. Политика обычно состоит из четырех цепочек, по одной для каждой подсистемы, хотя некоторые службы используют не все четыре подсистемы.
+Полный набор конфигурационных деклараций, описывающих, как обрабатывать запросы PAM к определённой услуге. Политика обычно состоит из четырёх цепочек, по одной для каждой подсистемы, хотя некоторые службы используют не все четыре подсистемы.
сервер (server)::
Приложение, выступающее от имени арбитратора для общения с клиентом, запрашивания аутентификационной информации, проверки полномочий аппликанта и подтверждающее или отклоняющее запрос.
@@ -134,7 +134,7 @@
Класс серверов, предоставляющих похожую или связанную функциональность, и требующую подобную аутентификацию. Политики PAM задаются на основе сервисов, так что ко всем серверам, объявляющим одно и тоже имя сервиса, будет применяться одна и та же политика.
сеанс (session)::
-Контекст, в котором сервис оказывается аппликанту сервером. Одна из четырех подсистем PAM, управление сеансом, касается исключительно настройке и очистке этого контекста.
+Контекст, в котором сервис оказывается аппликанту сервером. Одна из четырёх подсистем PAM, управление сеансом, касается исключительно настройке и очистке этого контекста.
ключ (token)::
Блок информации, связанный с учётной записью, например, пароль или ключевая фраза, которую аппликант должен предоставить для своей идентификации.
@@ -145,7 +145,7 @@
[[pam-usage-examples]]
=== Примеры использования
-Этот раздел предназначен для иллюстрации значений некоторых терминов, определенных выше, при помощи простых примеров.
+Этот раздел предназначен для иллюстрации значений некоторых терминов, определённых выше, при помощи простых примеров.
==== Объединенные клиент и сервер
@@ -166,7 +166,7 @@
....
* Аппликантом является `alice`.
-* Учетной записью является `root`.
+* Учётной записью является `root`.
* Процесс man:su[1] является как клиентом, так и сервером.
* Аутентификационным ключом является `xi3kiune`.
* Арбитратором выступает `root`, и именно поэтому у команды man:su[1] выставлен бит выполнения с правами `root`.
@@ -196,7 +196,7 @@
* Аппликантом является `eve`.
* Клиентом является процесс man:ssh[1] пользователя Eve.
* Сервером является процесс man:sshd[8] на машине `login.example.com`
-* Учетной записью является `bob`.
+* Учётной записью является `bob`.
* Ключом аутентификации является `god`.
* Хотя этого не видно в примере, но арбитратором является `root`.
@@ -233,18 +233,18 @@
** Функция 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] изменяет ключ аутентификации, опционально проверяя, что он труден для подбора, не использовался ранее и так далее.
@@ -274,7 +274,7 @@
Политика состоит из четырёх цепочек, по одной на каждый из методов PAM. Каждое звено представляет собой последовательность конфигурационных утверждений, задающих вызываемый модуль, некоторые (необязательные) параметры для передачи в модуль, и управляющий флаг, описывающий, как интерпретировать возвращаемый из модуля код.
-Понимание смысла управляющего флага необходимо для понимания конфигурационных файлов PAM. Существуют четыре различных управляющих флага:
+Понимание смысла управляющего флага необходимо для понимания конфигурационных файлов PAM. Существуют пять различных управляющих флагов:
`binding`::
Если модуль отработал успешно, и ни один из предыдущих модулей в цепочке не сработал отрицательно, то цепочка прерывается, а запрос подтверждается. Если же модуль отработает неудачно, то выполняется оставшаяся часть цепочки, однако запрос отвергается.
"Linux-PAM supports an alternate syntax that lets you specify the action to associate with each possible return code, but this should be avoided as it is non-standard and closely tied in with the way Linux-PAM dispatches service calls (which differs greatly from the way Solaris(TM) and OpenPAM do it.) \n"
"Unsurprisingly, OpenPAM does not support this syntax.\n"
msgstr ""
-"Точно также управляющий флаг является одним из четырёх ключевых слов, "
-"описанных в разделе\n"
-"\tcrossref:pam[pam-chains-policies, Цепочки и политики], в котором "
-"рассказано, как интерпретировать возвращаемый из модуля код.\n"
-" В Linux-PAM поддерживается альтернативный синтаксис, который позволяет "
-"указать действие, связанной с каждый возможным кодом возврата, но этого "
-"следует избегать, так как он не является стандартным и тесно связан со "
-"способом диспетчеризации вызовов сервисов в Linux-PAM (а он значительно "
-"отличается от способа взаимодействия в Solaris(TM) и OpenPAM).\n"
-" Не вызывает удивления тот факт, что в OpenPAM этот синтаксис не "
-"поддерживается.\n"
+"Точно также управляющий флаг является одним из четырёх ключевых слов, описанных в разделе\n"
+"\tcrossref:pam[pam-chains-policies, Цепочки и политики], в котором рассказано, как интерпретировать возвращаемый из модуля код.\n"
+" В Linux-PAM поддерживается альтернативный синтаксис, который позволяет указать действие, связанной с каждый возможным кодом возврата, но этого следует избегать, так как он не является стандартным и тесно связан со способом диспетчеризации вызовов сервисов в Linux-PAM (а он значительно отличается от способа взаимодействия в Solaris(TM) и OpenPAM).\n"
+" Не вызывает удивления тот факт, что в OpenPAM этот синтаксис не поддерживается.\n"