各PAM設定ファイルには、次のようなフォーマットされたディレクティブのグループが 含まれています:
<module interface> <control flag> <module path> <module arguments> |
これらのコンポーネントはそれぞれ次のセクションで説明してあります。
4つのタイプのPAMモジュールインターフェイスがあり、それぞれ認証プロセスの異なる側面に 関連しています:
auth — これらのモジュールは、例えばパスワードの要求とチェックを用いて、ユーザー認証を行います。 このインターフェイスのモジュールは、グループメンバーシップや、Kerberosチケットなどの証明書も設定できます。
account — これらのモジュールはアクセスが許可されることをチェックします。例えば、 ユーザーのアカウントが期限切れでないか、あるいはユーザーがその時刻のログインを認められているか、をチェックします。
password — これらのモジュールはパスワードの設定と確認に使用されます。
session — これらのモジュールはユーザーセッションを設定して管理します。 このインターフェイスのモジュールは、ユーザーのホームディレクトリのマウントやユーザーのメールボックスを 使用可能にするなどアクセスの許可に必要な追加のタスクを実行することが出来ます。
注意 | |
---|---|
個々のモジュールは上記の全てのモジュールインターフェイスあるいはそのいずれかを提供することができます。 例えば、pam_unix.soは4つのインターフェイスをすべて提供できます。 |
PAM設定ファイルでは、モジュールインターフェイスは最初に定義されるフィールドです。 例えば、設定の標準的な行は次のようになります:
auth required /lib/security/pam_unix.so |
これは PAMに対してpam_unix.soモジュールのauthインターフェイスを 使用するように指示しています。
モジュールインターフェイスディレクティブは、スタックされる、つまり次々に 置き換えられるので1つの目的の為に複数のモジュールが一緒に使用できます。従って、認証プロセスにおいて、 モジュールのスタック順は非常に重要です。
スタックにより、管理者がユーザーに認証を与える前に存在すべき特定の条件を要求することが 容易になります。例えば、rloginは、以下のPAM設定ファイルで示してある ように、通常、5つのスタックされたauthモジュールを使用します:
auth required /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_stack.so service=system-auth |
rloginの使用が認可される前に、PAMは/etc/nologinが存在しないこと、 暗号化されていないネットワーク接続を通じてrootとしてリモートからログインしようとしていないこと、どんな 環境変数でもロードできることを確認します。それがすべて適切ならrhostsの認証が実行され、 その接続が許可されます。rhostsの認証が失敗した場合は、通常のパスワード認証が実行され ます。
すべてのPAMモジュールは、コールがあると成功又は失敗の結果を生成します。制御フラグは、その結果に対する 処理方法をPAMに提供します。モジュールは特定の順序でスタックされるので、制御フラグは、ユーザーにその サービスへの認証をすることの全体的目的に対して、この特定のモジュールの成功あるいは失敗の重要度を判定 します。
4つのタイプの制御フラグが定義されています:
required — 認可が続行するにはモジュールの結果は成功でなければ いけません。requiredモジュールが失敗の結果を出すと、インターフェイスを 参照している全てのモジュールが完了するまで、ユーザーは結果報告を受け取りません。
requisite — 認可が続行するにはモジュールの結果は成功でなければ いけません。但し、requisiteモジュールの結果が失敗した場合、ユーザーは直ちに 最初に失敗したrequiredあるいはrequisiteモジュールに関する メッセージを受け取ります。
sufficient — チェックが失敗した場合、無視されるモジュールです。ただし、 sufficientフラグモジュールのチェックが成功し、そして その上部のrequiredフラグモジュールがすべて成功した場合、このタイプのほかの モジュールはチェックされず、ユーザーは認証されます。
optional — チェックが失敗した場合、無視されるモジュールです。 チェックに成功しても、結果はこのモジュールインターフェイスの成功や失敗に大した役割は しません。optionalフラグモジュールが認証の成功に必要になるのは、その インターフェイスを参照する他のモジュールがない時です。この場合、optional モジュールが、そのインターフェイス用の全体のPAM認証を決定します。
重要 | |
---|---|
requiredモジュールがコールされる順序は重要ではありません。 sufficientとrequisiteの制御フラグでは その順序が重要になります。 |
より正確な制御の為の新しい制御フラグの構文が現在PAM用に利用可能です。この新しい構文に関する 詳細は/usr/share/doc/pam-<version-number>/ ディレクトリ内にあるPAMドキュメントをお読み下さい。(<version-number>は PAMのバージョン番号です)。
モジュールパスによって、指定されたモジュールインターフェイスとともに使用するプラグ可能なモジュールの場所が PAMに知らされます。通常、/lib/security/pam_stack.soのようにモジュールへの フルパスが示されます。ただし、フルパスが提示されない場合、表示されたモジュールは、/lib/security/ ディレクトリ(PAMモジュールのデフォルトの位置)にあると判断されます。
PAMは、幾つかのモジュール用に認証をしている間、プラグ可能なモジュールへ情報を渡すために引数を使用します。
たとえば、pam_userdb.soモジュールは、Berkeley DBファイルに保存された 秘密鍵を使ってユーザーを認証します。 Berkeley DBは、多くのアプリケーションに組み込まれている オープンソースのデータベースシステムです。モジュールがdb引数を使用する ことによってBerkeley DBは要求されたサービスに使用するデータベースを判断できます。
PAM設定ファイルの中の標準的なpam_userdb.soの行は、以下のようになります:
auth required /lib/security/pam_userdb.so db=<path-to-file> |
直前の例では、<path-to-file>をBerkeley DBデータベースファイルの 完全パス名で入れ換えます。
無効な引数は無視され、PAMモジュールの成功あるいは失敗のどちらにも影響しません。 但し、殆どのモジュールではエラーが/var/log/messagesファイルに 表示されます。