Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
9
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

@satken2

PAM設定ファイルの意味と書き方メモ

PAMとは何か

Pluggable Authentication Modulesの略。ユーザー認証を行う仕組みです。

PAMの設定は/etc/pam.confまたは/etc/pam.d/配下にテキストファイルで記載されます。
PAMの内容は上から順に1行づつ評価されていき、各行は必ず成功か失敗かの結果を返します。
それぞれの成功、失敗を元に全体の認証の成否を決定します。

例:/etc/pam.d/common-auth

common-auth
#module-type    control                      module-path      arguments
auth            [success=1 default=ignore]   pam_unix.so      nullok_secure
auth            requisite                    pam_deny.so
auth            required                     pam_permit.so
auth            optional                     pam_cap.so

PAMの各行を構成する要素

上記の例を見ると分かる通り、各行はmodule-type, control, module-path, argumentsという4つの構成要素で構成されています。それぞれの意味を引用を交えて解説します。

引用部分は全てRedHatのドキュメンテーションからです。

module-type

Module-typeというのは、各モジュールが提供するインターフェース(機能)のことです。
例えば、pam-unix.soというモジュールは4つ全てのインターフェースを持っていて、例えばauthモジュールの場合はパスワードの認証を行い、accountモジュールの場合はアカウントの有効期限を確認するなど、同じモジュールでもインターフェースによって動作が異なります。

account

accountは、アカウントの有効性などを検証するモジュールタイプです。

このモジュールインターフェースは、ユーザーを認証します。たとえば、パスワードの有効性を要求したり検証したりします。このインターフェースがあるモジュールは、グループメンバーシップといった認証情報も設定できます。

モジュール accountインターフェースでできること
pam_unix.so アカウントの有効期限や有効/無効を判断する
pam_localuser.so /etc/passwdにユーザーが存在するかを確認する
pam_unix.so 入力されたパスワードを元に認証の許可/不許可を判断

auth

このモジュールインターフェースは、アクセスが許可されたことを確認します。たとえば、ユーザーアカウントの期限が切れたか、またはユーザーが 1 日の特定の時間にログインを許可されるかどうかをチェックします。

アカウント有効期間や有効性に関するモジュール

password

このモジュールインターフェースは、ユーザーのパスワード変更に使用されます。

パスワードの設定、確認に関するモジュール

session

このモジュールインターフェースは、ユーザーセッションを設定、管理します。このインターフェースのあるモジュールは、ユーザーのホームディレクトリーをマウントしたり、ユーザーのメールボックスを利用可能にするなど、アクセスの許可を必要とする追加タスクも実行できます。

ユーザーセッションを設定、管理に関するモジュール

control

各モジュールは実行されると必ず成功か失敗の結果を返します。
成功/失敗した場合にどのような挙動をするのかがcontrolです。

引用部分は全てRedHatのドキュメンテーションからです。

required

認証を継続するには、モジュール結果が成功する必要があります。この時点でテストが失敗すると、該当インターフェースを参照するすべてのモジュールテストの結果が完了するまでユーザーには通知されません。

文字通り「必須」。つまり必要条件。
このモジュールが失敗したら認証は失敗する。
ただし、このモジュールの成否はすぐにユーザーに通知されず、次に進む場合もある。

requisite

認証を継続するには、モジュール結果が成功する必要があります。ただし、この時点でテストが失敗するとユーザーに直ちに通知され、そのメッセージには最初に失敗した required または requisite モジュールテストが反映されます。

こちらも必要条件。このモジュールが失敗したら認証は失敗する。
ただし、requiredと違って失敗したらすぐにユーザーに通知される。

sufficient

モジュール結果は失敗した場合でも無視されます。ただし、sufficient のフラグの付いたモジュールが成功して、かつ required のフラグが付いたモジュールがそれまでに失敗していなければ、それ以上の結果は要求されず、ユーザーはサービスに認証されます。

これが成功すれば認証成功となる。
ただし、もしそれまでのrequiredに失敗があった場合(つまり必要条件が満たされていない場合)は認証されないので、十分条件ではない。失敗したら無視して次に進む。

optional

モジュール結果は無視されます。optional のフラグのついたモジュールは、他のモジュールが該当インターフェースを参照しない場合にのみ、認証成功に必要となります。

その他の条件指定方法

[success=ok default=ignore]などのようにさらに細かく指定する方法もあるが、ここでは割愛する。

module-path

ここでは、実際のモジュール名を指定します。
pathと書かれていますが、ほとんどの場合ファイル名だけで十分です。

arguments

モジュールに与える追加の情報を記載します。
無効な名前の引数は無視され、モジュールの実行結果に影響を与えることはありません。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
9
Help us understand the problem. What are the problem?