Внутреннее устройство Linux
Шрифт:
Существуют два типа управляющих аргументов: с простым и более сложным синтаксисом. Приведу три главных управляющих аргумента с простым синтаксисом, которые вы можете найти в правиле.
• sufficient. Если данное правило выполняется успешно, аутентификация также проходит успешно и PAM-утилите не нужно проверять следующие правила. Если правило не выполняется, утилита PAM переходит к дополнительным правилам.
• requisite. Если правило выполняется успешно, PAM-утилита переходит к следующим правилам. Если правило не выполняется, аутентификация завершается неудачей и PAM-утилите не нужно проверять следующие правила.
• required.
Продолжая предыдущий пример, приведу образец стека для функции аутентификации chsh:
auth sufficient pam_rootok.so
auth requisite pam_shells.so
auth sufficient pam_unix.so
auth required pam_deny.so
В соответствии с этой конфигурацией, после того как команда chsh запрашивает PAM-утилиту о выполнении функции аутентификации, утилита выполняет следующее (см. блок-схему на рис. 7.4).
1. Модуль pam_rootok.so проверяет, не пытается ли пройти аутентификацию корневой пользователь. Если это так, то происходит немедленное успешное завершение и дальнейшая аутентификация не предпринимается. Это срабатывает, поскольку для управляющего аргумента установлено значение sufficient, которое означает, что успешного завершения данного действия достаточно, чтобы утилита PAM немедленно возвратила результат команде chsh. В противном случае она переходит ко второму шагу.
2. Модуль pam_shells.so проверяет, есть ли оболочка пользователя в файле /etc/shells. Если ее там нет, модуль возвращает отказ, а управляющий аргумент requisite говорит о том, что утилита PAM должна немедленно сообщить об отказе команде chsh и не пытаться продолжать аутентификацию. В противном случае, когда оболочка есть в файле /etc/shells, модуль возвращает результат, который удовлетворяет флагу required, переходя к третьему шагу.
3. Модуль pam_unix.so запрашивает у пользователя пароль и проверяет его. Для управляющего аргумента указано значение sufficient, поэтому успешной проверки (пароль верный) достаточно для утилиты PAM, чтобы она сообщила об этом команде chsh. Если пароль неверный, утилита PAM переходит к четвертому шагу.
4. Модуль pam_deny.so всегда вызывает отказ, а поскольку присутствует управляющий аргумент required, утилита PAM возвращает отказ команде chsh. Этот вариант применяется по умолчанию в тех случаях, когда больше нечего пробовать. Обратите внимание на то, что управляющий аргумент required не приводит к моментальному отказу функции PAM — она обработает все остальные строки стека, — однако в результате в приложение всегда вернется отказ.
примечание
Не смешивайте термины «функция» и «действие», когда работаете с утилитой PAM. Функция является целью верхнего уровня: что ожидает пользовательское приложение от утилиты PAM (например, выполнить аутентификацию пользователя). Действие является отдельным шагом, который выполняет утилита, чтобы достичь цели. Запомните лишь то, что сначала пользовательское приложение вызывает функцию, а утилита PAM заботится обо всех деталях, связанных с действиями.
Сложный синтаксис управляющего аргумента, помещаемый внутри квадратных скобок ([]), позволяет вручную контролировать реакцию, основываясь на специальном значении,
Рис. 7.4. Процесс исполнения правила PAM
Аргументы модуля
Модули PAM могут задействовать аргументы после имени модуля. Вам часто будет встречаться такой вариант для модуля pam_unix.so:
auth sufficient pam_unix.so nullok
Здесь аргумент nullok сообщает о том, что у пользователя может не быть пароля (по умолчанию в таком случае возник бы отказ).
7.10.2. Примечания о стандарте PAM
Благодаря возможности управления процессом и модульному синтаксису аргументов синтаксис PAM-конфигурации обладает многими чертами языка программирования и некоторыми функциональными возможностями. Мы лишь слегка затронули эту тему, однако приведу еще несколько моментов, относящихся к стандарту PAM.
• Чтобы выяснить, какие модули PAM присутствуют в вашей системе, воспользуйтесь командой man –k pam_ (обратите внимание на символ подчеркивания). Может оказаться непросто выяснить местоположение модулей. Попробуйте команду locate unix_pam.so и посмотрите, к чему это приведет.
• Страницы руководства содержат описание функций и аргументов для каждого модуля.
• Многие версии системы автоматически генерируют некоторые файлы конфигурации PAM, поэтому неразумно изменять их напрямую в каталоге /etc/pam.d. Прочитайте комментарии в этих файлах перед их редактированием; если они были сгенерированы, комментарии скажут вам, откуда взялись файлы.
• Конфигурационные файлы в каталоге /etc/pam.d/other определяют конфигурацию по умолчанию для любого приложения, у которого нет собственного файла конфигурации. Часто по умолчанию на все следует отказ.
• Существуют разные способы включения дополнительных файлов конфигурации в файл конфигурации PAM. Синтаксис @include загружает весь файл конфигурации, но можно также использовать управляющий аргумент, чтобы загрузить только конфигурацию для конкретной функции. Способ использования разный для различных версий системы.
• Конфигурация PAM не ограничивается лишь аргументами модуля. Некоторые модули могут иметь доступ к дополнительным файлам в каталоге /etc/security, как правило, для настройки ограничений для отдельного пользователя.
7.10.3. Стандарт PAM и пароли
В результате эволюции системы проверки паролей в Linux сохранилось несколько артефактов, которые иногда могут привести к путанице. Во-первых, следует опасаться файла /etc/login.defs. Это файл конфигурации для исходного набора shadow-паролей. Он содержит информацию об алгоритме шифрования, использованном для файла shadow, однако редко применяется в современных системах с установленными модулями PAM, поскольку конфигурация PAM уже содержит данную информацию. Учитывая сказанное, алгоритм шифрования, указанный в файле /etc/login.defs, должен совпадать с конфигурацией PAM — для тех редких случаев, когда вам встретится приложение, не поддерживающее стандарт PAM.