オフィスには複数台のロボットが生息していますが、お掃除ロボット Roomba 570 はその中でも新参者です。
Roomba 570の続きを読む
2008年3月アーカイブ
何か不可解な挙動に遭遇した時にソースを参照する、ということはよくやるのですが、そういう頻繁に発生するタスクは効率よくこなしたいものです。
まず、私の場合は参照するソースは FreeBSD の ports システムが /usr/ports に展開されています。インストールするものは大抵 ports 経由となっています。
例えば PostgreSQL のソースを参照したい場合は
% cd /usr/ports/databases/postgresql83-server
% sudo make patch
% cd `make -VWRKSRC`
という手順で、ソースの展開されたディレクトリに移動できます。ソースファイルが手元になければ make patch の部分で勝手に外から取ってきます。
実際には、三行目は pushd make -VWRKSRC とディレクトリスタックに積むようにしてあり、さらに pdw というエイリアスを作って楽をしています。
あとは、grep(1) なり ack なりで、ソースの探索を開始！ というわけ。
普段は PostgreSQL 内にパスワードを保存する、password (md5) な認証方式を使うのですが、必要なスタッフ分のパスワードをサーバ構築ごとに設定するのも面倒なため、認証をまとめられないかな、と思って調べてみました。
うちの環境では Kerberos は使っていないのでこれはパス。
LDAP は利用しているので、これが楽かなあ、と思いつつ、ネットワーク上のほかのサーバに依存する、というのは DB 用の環境としてはちょっと避けたいのでこれも一旦パス。
ということで、PAM で行ってみることにしました。
PAM を使う設定は簡単で、pg_hba.conf に
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all kuriyama 192.168.0.0/24 pam
と記述し、/etc/pam.d/postgresql (FreeBSD の場合) に
auth required pam_unix.so no_warn try_first_pass
と記述したものを新規に作成します。
これで OK、と思ったのですが、認証用のプロンプト(PAM経由)は出てくるものの、正しいパスワードを入れても
pam_authenticate failed: authentication error
というエラーになってしまいます。おかしいなあ、と思い、PostgreSQL のソースコードの PAM まわりの手順を確認して、問題なさそうと思いつつ簡単なテストコードを書いて、他の PAM 利用ツールと比較してみたりしました。
手順は特に問題なさそう。
ふとそのテストコードを root 権限で試してみると、こちらは認証が成功します！
そりゃそうだ。PAM は pluggable な共有ライブラリとして存在しているので、ライブラリのコードが実行されるのは、呼び出す側のプログラムの実行権限に依存します。そして pam_unix.so の認証は、getpwent(3) を使うので、root 権限ではパスワードハッシュが取得できるけどそれ以外の権限ではその部分が空の struct passwd 構造体しか返ってこない。PostgreSQL のデーモンも、専用のユーザー権限で動いているので、pam_unix.so の認証は必ず失敗する、ということでした。
試しに別の PAM 認証 (pam_ssh.so など) を試したところ、こちらではうまく認証されました。が、ちょっとこれだと今回の私の目的とは合わないのでパス。
というわけで、PostgreSQL の PAM 認証は私の用途では使えない、ということのようです。うーむ、何か他に手はないかなあ。
ちなみに、参考にした su(1), login(1) などは、root 権限に setuid されているので、問題なく pam_unix.so を使うことができるようになっています。
