PAM (Pluggable Authentication Modules) は現在的な ディストリビューションにおけるユーザ認証の核となるものです。
古き良き時代の Linux であれば、su や passwd や login あるいは xlock と いったプログラムは、ユーザ認証の必要が生じた時に、/etc/passwd から必要なユーザ情報を読み込めばいいだけでした。 ユーザパスワードの変更が必要なら、/etc/passwd ファイルを 編集するだけでした。 しかし、この単純ですが稚拙な方法のために、システム管理者やアプリケーション 開発者は数々の問題に直面することになったのです。MD5 とシャドーパスワードの利用 がだんだんと広がるにつれて、ユーザ認証を必要とするプログラムは、何種類もの異 なる認証方法を扱う際にその認証方法に適した情報を得る手段を個別に知っていなけ ればならなくなったからです。また、認証方式を変更したい場合は、そうしたすべて のプログラムをコンパイルし直さなければなりませんでした。PAM は、ユーザ情報が 保存される方法とは無関係な透過的ユーザ認証方式をプログラムに提供することで、 この煩雑な手続きを一掃したのです。
Linux-PAM System Administrator's Guide から引用すると、「Linux-PAM プロジェクトの目的は、ユーザに何らかの権限を付与するソフトウェアの開発を、 安全かつ適切な認証方式自体の開発から分離することです。この目標は、関数のライ ブラリを提供し、アプリケーション側でそれを使ってユーザ認証をリクエストする 仕組みを作ることで達成されました。」 つまり、PAM があれば、パスワードが /etc/passwd にあるか、 香港のサーバ上にあるかといったことは問題ではなくなります。プログラムがユーザ 認証を必要としたときは、PAM が適切な認証方式のための関数を含むライブラリを提供 してくれます。このライブラリは動的にロードされるので、認証方式の変更は設定 ファイルの編集だけで実現可能になるのです。
柔軟性は PAM が最強である理由のひとつです。PAM の設定によって、あるプログラム のユーザ認証権の行使を禁止したり、特定のユーザだけの認証を可能にしたり、あ るいは、プログラムがユーザ認証をしようとすると警告を発したり、さらに全ての ユーザをログインできなくしてしまったりできるようになります。PAM のモジュール 設計は、ユーザ認証方法の完全な管理を可能にします。
いずれほとんど全ての有名ディストリビューションが PAM をサポートするでしょう。 以下は不完全ですが、 PAM をサポートしているディストリビューションの一覧です。
Redhat バージョン 5.0 以降
Mandrake 5.2 以降
Debian バージョン 2.1 以降( 2.1 では部分的サポート、2.2 で完全 サポート)
Caldera バージョン 1.3 以降
Turbolinux バージョン 3.6 以降
SuSE バージョン 6.2 以降
(訳注) Vine すべてのバージョン
(訳注) Kondara すべてのバージョン
上記リストは、不完全なはずですし、不正確でもあるでしょう。このリストへの追 加や修正情報を送ってくれるとうれしいです。 petehern@yahoo.com
PAM をソースからインストールすることは、時間のかかる作業であり、この HOWTO の 範疇を越えるものです。システムに PAM がインストールされていないなら、おそら く、アップグレードすべき理由が他にもいろいろある古いバージョンのディス トリビューションを使っているからでしょう。また、自分でインストールしなければ 気が済まないという人なら、わたしの手助けは不要なはずです。いずれにせよ、ここ からは、既に PAM がインストールされていることを前提にします。
一般的な話はこれくらいにして、問題を掘り下げましょう。
PAM の設定ファイルは、/etc/pam.d に保存されています。 (もし /etc/pam.d というディレクトリが ないとしても心配いりません。次章で取り上げます。) そのディレクトリに行って、 中を覗いてみましょう。
~$ cd /etc/pam.d /etc/pam.d/$ ls chfn chsh login other passwd su xlock /etc/pam.d/$ |
システムに何をインストールしているかによって、このディレクトリにあるファイルは 多少増減するかもしれません。詳細はどうであれ、システム上でユーザの認証に関わ るプログラムごとにひとつのファイルが存在することが分かると思います。既に気付 いたかもしれませんが、どのファイルも PAM による認証の設定ファイルなのですが、 それぞれ該当するプログラムと同一の名前が付いています。 ( other だけが例外です が、これはすこし後で話します。) それではパスワードに関連した PAM の設定ファイ ルを見てみましょう。(次のファイルは分かり易くするために単純化してあります。)
/etc/pam.d/$ cat login # PAM 設定ファイル( login プログラム用 ) auth requisite pam_securetty.so auth required pam_nologin.so auth required pam_env.so auth required pam_unix.so nulok account required pam_unix.so session required pam_unix.so session optional pam_lastlog.so password required pam_unix.so nullok obscure min=4 max=8 |
このファイルを掘り下げる前に、少し説明すべきことがあります。
少数の方はこう考えているかもしれません。「えっ！ /etc/pam.d ディレクトリなんてない。 ディストリビューションの収録 プログラムリストに PAM は含まれているのに、ディレクトリが見つからない。PAM が ない人生なんて、空っぽで無意味だ！ どうすればいいんだろう？」 心配無用です。 無くなったのではありません。ディストリビューションに PAM が含まれているのに、 /etc/pam.d がないときは、PAM の設定 ファイルは /etc/pam.conf に保存されているのです。 いくつものファイルに分散させるかわりに、PAM の設定ファイルをまとめてひとつの ファイルに保存しているのです。 この場合、PAM の設定はすこしだけ異なった構文になりますが、そこでの設定 については この章の Section 3.3.4 「 pam.conf ファイルの設定」で説明します。
PAM の設定ファイルは以下のような構文になっています。
type control module-path module-arguments |
login プログラム(先ほどの記述を見てください)の設定 ファイルを参考にして、PAM 設定ファイルの構文を見てみましょう。
PAM の設定字句
type という字句では、その行のモジュールでどういう認証の型が使用 されるべきかを PAM に知らせます。 認証の際に複数の要求をユーザに課す場合は、同じ型のモジュールを 重複して使用することもできます。PAM は次の 4 つの型を認識します。
ユーザがサービスへのアクセスを許可されているかどうか、パスワードが期限 切れになっていないかなどを(パスワードとは無関係に)確認します。
ユーザが自称する通りの本物のユーザかどうかを確かめます。通常はパスワード で確認しますが、バイオメトリクス(biometrics)などのもっと洗練された方法で確かめ る場合があるかもしれません。
ユーザに自分の認証方法を変更するメカニズムを提供します。これも通常はパス ワードの変更によってなされます。
ユーザの認証前または認証後、あるいはその両方で実行したいことを指定しま す。これには、ユーザディレクトリのマウントやアンマウント、ログインやログアウト 時のログ記録、ユーザが利用できるサービスを制限したり、その制限を外したりといっ たことがなどが含まれるでしょう。
上記 login の設定ファイルでは、type の各々の型 が最低でもひとつのエントリーを形成しているのが分かると思います。 login プログラムは、その名前の通りユーザの「ログイン」そのも のを許可するプログラムなので、認証の過程ですべての異なった型にアクセスす る必要があることは納得できると思います。
control 字句が果たす役割は、認証が失敗したときに何をすべきかを PAM に伝えることです。PAM が理解するのは次の 4 つの control 型 です。
このモジュールを経由して認証に失敗した場合に、即座に認証を拒絶します。
認証に失敗した場合に、認証を拒否します。しかし、PAM は、認証拒否をユーザ に知らせる前に、このサービスのためにリストアップされた(同一 type の)全てのモジュールを実行します。
このモジュールによる認証が成功した場合、その前の required 型のモジュールが認証に失敗していたとしても、PAM はそのユーザに認証を与えま す。
このモジュールが認証の成否に関して意味を持つのは、そのサービスに関して、 これが(認証の成否を決めるべき)唯一のモジュール型である場合だけです。
login プログラムの設定ファイルでは、異なる control 型のほぼ全てを見ることができます。required 型のモジュール の大部分は pam_unix.so (メインの認証モジュール)です。 そして、ひとつの requisite 型のモジュールが pam_securefilenamey.so (ユーザが安全なコンソールでログインしているか 確かめるもの)であり、ひとつの optional 型のモジュールが pam_lastlogin.so (前回ログインしたときのユーザの情報を取ってくる モジュール)となっています。
(訳注: control については、新しい構文も開発されています。 詳細は、The Linux-PAM System Administrators' Guide をご覧ください)
module-path の役割は、どのモジュールを使用するか、(オプションとし て)それがどこにあるかを PAM に伝えることです。login の設定 ファイルに見られるように、大部分の設定ファイルではモジュール名だけが含まれてい ます。この場合、PAM は、PAM 用のデフォルトディレクトリ、通常は /usr/lib/security/ を探します。しかし、 もし使っているディストリビューションが Linux ファイルシステムの標準規格に従って いるなら、PAM モジュールは /lib/security ディレクトリにあるでしょう。
module-arguments は、モジュールに渡す引数を指定するものです。 それぞれのモジュールが自分自身の引数を持っています。例えば、login の設定ファイルであれば、"nullok" ("null ok" を意味します)という引数は、pam_unix.so モジュールに渡されますが、その意味は、パスワードとして何も入力しな くても(null)認証されるということです。
もし PAM の設定が /etc/pam.d/ ディレク トリではなく、/etc/pam.conf ファイルに保存されているなら、 PAM の設定の書式は若干異なったものになります。サービスごとに設定ファイルを持つ のではなく、全ての設定が /etc/pam.conf ファイルの中で行わ れ、サービス名が各行の先頭の識別情報となります。例えば、/etc/pam.d/login ファイルの次の行は、
auth required pam_unix.so
|
/etc/pam.conf ファイルでは、以下のようになる でしょう。
login auth required pam_unix.so
|
上記のちょっとした違いを除けば、残りの全ての PAM の構文がそのまま当てはまり ます。
PAM の設定や PAM の全モジュールのリファレンスなど、より詳細な情報が必要なとき は、Linux-PAM System Administrator's Guide を参考にしてください。 このガイドは、PAM の設定に関するあらゆることを説明するもので、最新のリファレ ンスでもあります。