PAM スタック

アプリケーションが次のいずれかの関数を呼び出すと、PAM フレームワークは PAM 構成ファイルを読み取って、どのモジュールがこのアプリケーションの PAM サービス名を実装するかを決定します。

• pam_authenticate(3PAM)

• pam_acct_mgmt(3PAM)

• pam_setcred(3PAM)

• pam_open_session(3PAM)

• pam_close_session(3PAM)

• pam_chauthtok(3PAM)

構成ファイルに 1 つのモジュールしか含まれていない場合は、そのモジュールの結果によってこの操作の結果が決定されます。たとえば、passwd アプリケーションのデフォルトの認証操作には、/etc/pam.d/passwd ファイル内に 1 つのモジュール pam_passwd_auth.so.1 が含まれています。

auth required           pam_passwd_auth.so.1

これに対して、サービスが複数のモジュールで実装されている場合は、これらのモジュールをスタックと呼びます。つまり、そのサービス名に対して PAM スタックが存在します。たとえば、サンプルの /etc/pam.d/login サービス内のエントリを考えてみます。

auth definitive         pam_user_policy.so.1
auth requisite          pam_authtok_get.so.1
auth required           pam_unix_auth.so.1
auth required           pam_dhkeys.so.1
auth required           pam_unix_cred.so.1
auth required           pam_dial_auth.so.1

これらのエントリは、login サービス名の auth スタックを作成します。このスタックの結果を決定するには、個々のモジュールの結果コードに対して「統合プロセス」を実行する必要があります。

統合プロセスでは、各モジュールがファイル内の順序に従って実行されます。それぞれの成功または失敗コードが、モジュールの制御フラグに従って、全体的な結果に統合されます。制御フラグによっては、スタックの早期終了が発生する可能性があります。たとえば、requisite または definitive モジュールの失敗によってスタックが終了します。その前に失敗がない場合は、sufficient、definitive、または binding モジュールの成功によってもスタックが終了します。スタックが処理されたあと、個々の結果が、アプリケーションに配信される 1 つの全体的な結果に結合されます。このフローのグラフィックビューについては、Figure 1–2 およびFigure 1–3 を参照してください。

制御フラグは、成功または失敗の決定において PAM モジュールが果たす役割を示します。制御フラグとその効果は、次のとおりです。

• binding – binding モジュールの要件を満たすことに成功すると、以前の失敗が記録されていない場合は、成功がただちにアプリケーションに返されます。これらの条件が満たされると、後続のモジュールは実行されません。

  失敗すると、required 失敗が記録され、モジュールの処理が継続されます。

• definitive – definitive モジュールの要件を満たすことに成功すると、以前の失敗が記録されていない場合は、成功がただちにアプリケーションに返されます。

  以前の失敗が記録されている場合は、その失敗がただちにアプリケーションに返され、モジュールはそれ以上実行されません。失敗するとすぐにエラーが返され、後続のモジュールは実行されません。

• include – 別の PAM 構成ファイルから、PAM スタック内のこの時点で使用される行を追加します。このフラグは成功または失敗の動作を制御しません。新しいファイルが読み取られると、PAM の include スタックが 1 増やされます。新しいファイル内でのスタックチェックが完了すると、include スタックの値が 1 減らされます。ファイルの最後に達したときに、PAM の include スタックが 0 である場合は、スタックの処理が終了します。PAM の include スタックの最大数は 32 です。

• optional – optional モジュールの要件を満たすことに成功することは、サービスを使用するために必要ではありません。

  失敗すると、optional 失敗が記録されます。

• required – required モジュールの要件を満たすことに成功することは、スタックが成功するために必要です。スタックの最終的な成功が返されるのは、どの binding または required モジュールも失敗を報告しなかった場合だけです。

  失敗すると、このサービスの残りのモジュールの実行完了後に、エラーが返されます。

• requisite – requisite モジュールの要件を満たすことに成功することは、スタックが成功するために必要です。スタックがアプリケーションに成功を返せるようにするには、スタック内のすべての requisite モジュールが成功を返す必要があります。

  失敗するとすぐにエラーが返され、後続のモジュールは実行されません。

• sufficient – 以前のどの required の失敗も記録されていない場合は、sufficient モジュールが成功するとただちに成功が返され、モジュールはそれ以上実行されません。

  失敗すると、optional 失敗が記録されます。

次の 2 つの接続図は、統合プロセスで結果がどのように決定されるかを示しています。

• 最初の図は、制御フラグのタイプごとに成功または失敗がどのように記録されるかを示しています。これらの結果は、2 番目の図に示されています。

• 2 番目の図は、統合された値の決定方法を示しています。optional の失敗と required の失敗は失敗を返し、成功は成功を返します。アプリケーションは、これらのリターンコードを処理する方法を決定します。

図 1-2  PAM スタック: 制御フラグの効果

図 1-3  PAM スタック: 統合された値の決定方法