/etc/pam.conf
pam.conf, pam.d - PAM configuration files
DESCRIPTION
PAM を意識した特権付与アプリケーションが起動すると、PAM-API へのアタッチメントがアクティブになる。この起動はいくつかのタスクを実行するが、最も重要なのは設定ファイル (複数可) を読み込むことである。/etc/pam.conf を読み込むことである。あるいは、/etc/pam.d/ディレクトリの内容であってもかまわない。このディレクトリが存在すると、Linux-PAMは/etc/pam.confを無視するようになる。
これらのファイルには、このサービスで必要とされる認証作業を行う PAM と、個々の PAM が失敗した場合の PAM-API の適切な動作が記述されている。
設定ファイル /etc/pam.conf の構文は以下のとおりです。このファイルはルールの一覧で構成されており、各ルールは通常1行に配置されるが、行末をエスケープして拡張することがでる:
`\<LF>'
コメントは `#' マークで始まり、次の行の終わりまで続く。
各ルールの形式は、スペースで区切られたトークンの集まりであり、最初の3つは大文字小文字を区別しない。
service type control module-path module-arguments
/etc/pam.d/ディレクトリに含まれるファイルの構文は、serviceフィールドがないことを除けば同一である。この場合、serviceは/etc/pam.d/ディレクトリのファイル名となる。このファイル名は小文字でなければならない。
PAM の重要な特徴として、いくつかのルールを積み重ねて、 ある認証タスクに対して複数の PAM のサービスを組み合わせることが できるということがある。
service名は、通常、対応するアプリケーションのおなじみの名前である。 loginとsuが良い例である。サービス名 other は、デフォルトの規則を指定するために予約されている。現在のservice (あるいはそれがない場合は他のエントリ) に言及している行だけが、指定したサービスアプリケーションと関連付けられる。
typeは、ルールが対応する管理グループである。これは、後続のmoduleがどの管理グループと関連付けられるかを指定するために使用される。有効なエントリは以下の通り:
- account
- このmodule typeは、非認証ベースのアカウント管理を行う。これは通常、時間帯や現在利用可能なシステムリソース (最大ユーザー数)、あるいは申請ユーザーの所在地に基づいてserviceへのアクセスを制限/許可するために使われる -- コンソール上では 'root' ログインのみである。
- auth
- このmodule typeは、ユーザーを認証するための二つの側面を提供します。第一に、アプリケーションにパスワードや他の識別手段を要求するよう指示することで、 ユーザが本人であることを証明する。第二に、このmoduleは資格付与のプロパティを通じてグループメンバーや他の特権を付与することができる。
- password
- このmodule typeは、ユーザーに関連付けられた認証トークンを更新するために必要である。通常、「チャレンジ/レスポンス」ベースの認証(auth)タイプごとに1つのモジュールが存在する。
- session
- このmodule typeは、ユーザーにサービスを提供する前に、あるいは提供した後に、ユーザーのために必要なことを行うことに関連している。このようなことには、ユーザとのデータ交換のオープン/クローズに関する情報のロギングや、ディレクトリのマウントなどが含まれる。
- 上のリストの型の値の前に - 文字がある場合、PAM ライブラリはシステムでmoduleが見つからないためにロードできない場合、システムログにログを残さない。これは、特に、常にシステムにインストールされているわけではなく、ログインセッションの正しい認証と承認に必要でないmodule に便利である。
- 3 番目のフィールドである control は、moduleが認証に失敗した場合の PAM-API の振る舞いを指定する。この制御フィールドには2種類の構文がある。単純なものは単一のキーワードを持ち、 より複雑なものは角括弧で囲まれた値=アクションのペアを選択するものである。
単純な(歴史的な)構文では、有効な制御値は以下の通りである。
- required
- このようなPAMの失敗は、最終的にPAM-APIが失敗を返すことになるが、それは(このserviceとtypeの)残りのスタックモジュールが呼び出された後にのみ起こる。
- requisite
- ただし、必須moduleと同様に、このようなmoduleが失敗を返した場合、制御は直接アプリケーションまたは上位のPAMスタックに返されます。戻り値は、最初に失敗した required または requisite moduleに関連するものである。注意:このフラグは、ユーザーが安全でない媒体を介してパスワードを入力する機会を得る可能性から保護するために使用することができる。このような動作は、システム上の有効なアカウントを攻撃者に知らせる可能性がある。この可能性は、敵対的な環境で機密のパスワードを公開することの重大な懸念と比較検討されるべきである。
- sufficient
- このようなmoduleが成功し、事前に必要なmoduleが失敗していない場合、PAM フレームワークは、スタック内のそれ以上のmoduleを呼び出すことなく、アプリケーションまたは上位の PAM スタックに直ちに成功を返す。十分なmoduleの失敗は無視され、PAM モジュールスタックの処理は影響を受けずに続行される。
- optional
- このmoduleの成否は、このservice+typeに関連するスタック内の唯一のmoduleである場合にのみ重要である。
- include
- このコントロールの引数として指定された設定ファイルから、指定されたtypeの行をすべてインクルードする。
- substack
- この制御の引数として指定された構成ファイルから、指定されたtypeの行をすべて含める。include とは異なり、サブスタック内の done と die アクションの評価では、モジュールスタック全体の残りはスキップされず、サブスタックのみがスキップされる。また、サブスタック内でのジャンプは、評価をその外にジャンプさせることはできず、親スタックでジャンプが行われた場合、サブスタック全体が1つのモジュールとしてカウントされる。リセットアクションは、モジュールスタックの状態をサブスタックの評価開始時点の状態にリセットする。
- より複雑な構文では、有効な制御値は次のような形式となる。
[value1=action1 value2=action2 ...]
- ここで、valueN は、その行が定義されているモジュールで呼び出された関数の戻りコードに相当する。以下のいずれかから選択される。success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired.SESSION_err, no_module_data, conv_err, cred_outvail, cred_expired.SESSION_err, cred_insufficient_unavail, user_unknown, unavail, new_authtok_recd cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete そして default である。
- これらのうち、最後の default は、明示的に言及されていないすべての valueN を意味する。PAM のエラーの完全なリストは /usr/include/security/_pam_types.h にあることに注意すること。
- ignore
- moduleのスタックで使用する場合、moduleの戻りステータスは、アプリケーションが取得する戻りコードに寄与しない。
- bad
- このアクションは、リターンコードがmoduleの失敗を示すと考えるべきであることを示す。このmoduleがスタックの中で最初に失敗した場合、その状態値はスタック全体の状態値として使用される。
- die
- モジュールスタックを終了させ、PAMがすぐにアプリケーションに戻るという副作用を持つbadと同等である。
- ok
- これは、管理者がこのリターンコードがmoduleのフルスタックのリターンコードに直接寄与するべきだと考えていることを PAM に伝える。言い換えると、もし以前のスタックの状態が PAM_SUCCESS を返すようなものであれば、moduleのリターンコードはこの値を上書きすることになる。注意: もしスタックの以前の状態がmoduleの失敗を示す何らかの値を保持している場合、 この 'ok' 値はその値を上書きするために使われることはある。
- done
- モジュールスタックを終了させ、PAMがすぐにアプリケーションに戻るという副作用があるが、okと同等である。
- N (an unsigned integer)
- スタック内の次の N 個のmoduleにジャンプする。N が 0 であることは許されないので、その場合は無視されることに注意すること。pam_authenticate, pam_acct_mgmt, pam_chauthtok, pam_open_session では ignore、 pam_setcred と pam_close_session ではmodule の戻り値に応じて ignore, ok, bad のいずれかになる。
- reset
- モジュールスタックの状態のすべてのメモリをクリアし、次のスタックモジュールで再スタートする。
required、requisite、sufficient、optionalの4つのキーワードは、それぞれ[...]構文で等価な表現が可能である。それらは次の通りである。
- required
- [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
- requisite
- [success=ok new_authtok_reqd=ok ignore=ignore default=die]
- sufficient
- [success=done new_authtok_reqd=done default=ignore]
- optional
- [success=ok new_authtok_reqd=ok default=ignore]
module-path は、アプリケーションで使用する PAM の完全なファイル名 (先頭が '/') か、デフォルトの module の場所からの相対パス名である。アーキテクチャに応じて、/lib/security/ または /lib64/security/ から相対パス名を指定する。
module-arguments は、与えられた PAM の特定の動作を変更するために使用できるトークンのスペース区切りのリストである。このような引数は、個々の module ごとに文書化される。注意:もし引数にスペースを入れたい場合は、その引数を角括弧で囲む必要がある。
squid auth required pam_mysql.so user=passwd_query passwd=mada \
db=eminence [query=select user_name from internet_service \
where user_name='%u' and password=PASSWORD('%p') and \
service='web_proxy']
この規約を使う場合、文字列の中に `[' 文字を含めることができ、引数の解析に耐えられるような `]' 文字を文字列の中に含めたい場合は `[]' を使う必要がある。つまり
[..[..\]..] --> ..[..]..
設定ファイル (のひとつ) の中で、正しくフォーマットされていない行は、 一般的に (慎重になるべきところから) 認証プロセスを失敗させる傾向がある。対応するエラーは、 syslog(3) の呼び出しにより、システムログファイルに書き込まれる。
単一の設定ファイルよりも柔軟なのは、/etc/pam.d/ ディレクトリの内容を使って libpam を設定することである。この場合、ディレクトリはservice名 (小文字) に等しいファイル名を持つファイルで埋め尽くされる: これは、その名前のserviceの個人用設定ファイルである。
/etc/pam.d/の各ファイルの構文は、/etc/pam.confファイルの構文と似ており、次のような形式の行から構成されている。
- type control module-path module-arguments
唯一の違いは、service-nameが存在しないことです。もちろん、service-nameは与えられた設定ファイルの名前である。例えば、/etc/pam.d/loginには、ログインサービスの設定が含まれている。
SEE ALSO
External link
この記事は、Debianのmanpageの項目を翻訳一部改変しております。 |