月別アーカイブ: 2005年9月

Apache の digest 認証

Apache で Digest 認証を行う場合、認証のためのパスワードデータベースは htdigest によって作成します。そのデータベースは username:realm:passwd-digest となっていますが、passwd-digest の部分は username:realm:passwd の MD5 によるハッシュ値です。
ここで疑問が生じました。Digest 認証といえばチャレンジ-レスポンスによる認証で、サーバーは生のパスワードを知らないと認証できなかったはずです。CRAM-MD5 ではたしかそうだったはずです。Apache はパスワードのハッシュ値しか持たずにどうやって認証するんでしょうか?
ということで調べてみました。
HTTP の Digest 認証で通信経路を流れるのは先の passwd-digest を基にチャレンジ-レスポンスによる認証を行います。したがって、passwd-digest 自身がチャレンジ-レスポンスの際の生のパスワードに相当しますが、通信経路を流れるのは passwd-digest とサーバのチャレンジから生成したハッシュ値なので、通信の傍受に対して Basic 認証より安全であるというのは確かなようです。
しかし、サーバに保存されている passwd-digest の値が漏洩した場合は Digest 認証は生のパスワードが漏洩した場合と同様に、成りすましに対して無防備になります。これはチャレンジ-レスポンスによる認証方式一般に言えることなので仕方がありませんが、これでは生のパスワードを直接保存するのではなく、ハッシュ値を保存してそれを使用するようにしている理由がわかりません。
その理由は RFC2617 にありました。

それは、あるダイジェスト認証パスワードファイルが危険に晒された場合、同じユーザ名やパスワードを持つその他のものを危険に晒す事はない (しかし総当たり攻撃には晒される) という事を意味する。

パスワードファイルが漏洩した場合に総当り攻撃に晒されるというのは Basic 認証のパスワードファイルでも同じです。パスワードファイルが漏洩したときの HTTP の認証に対する成りすましの危険度は Digest 認証の方が高いようですが、総合的に見て Basic 認証より Digest 認証の方が安全だということなのでしょう。
参考 URL

Analog のインストール

Web ログ解析のために Analog をインストールしました。例によって pkgsrc からインストールです。以前にインストールしたのはずいぶん前のことなのですっかり忘れていてちょっと苦労しました。
pkgsrc では 6.0 になっています。日本語EUC版のフォームが /usr/pkg/lib/analog/lang/jpeform.html にインストールされているのでこれをコピーして修正します。Analog を CGI として使うには anlgform.pl を使いますが、pkgsrc ではインストールされません。Analog の配布パッケージには含まれているので展開してコピーしてきます。ずっと前もそんなことをしたような気がしますが、そのときと同じくらいはまりました。
一通り設定が終わって実行してみたのですが、ファイルのダウンロードのダイアログが表示されてしまいました。これは IE6 でやっていたので w3m でもやってみたのですが、w3m でもファイルを保存しようとしてしまいます。保存したファイルを見ると一応期待するような XHTML の出力にはなっています。
調べてみると Content-Type が application/xhtml+xml になっていました。どうやらこれが原因のようです。analog.cfg で OUTPUT HTML にすると Content-Type が text/html になるようですが、出力されるのは HTML 2.0 なので CSS の指定ができません。
設定で回避はできないようなので、anlgform.pl で analog の出力を強引に書き換えることにしました。

     die;
}
else {
-    open (ANALOG, "|$analog +g-");  # errors here will get caught on close
+    open (ANALOG, "|$analog +g-|/usr/bin/sed '1s,application/xhtml+xml,text/html,'");  # errors here will get caught on close
}
# 3) PRINT ALL THE COMMANDS

続きを読む

PHP5 のインストール

再構築中の NetBSD のサーバに PHP をインストールしました。以前のシステムでは PHP4 を入れていたのですが、これを機会に PHP5 に移行しようと思って、PHP5 の方を入れることにしました。 もともとPHP4 を使い込んでいたわけでもないのでそれほど移行に障害があるわけでもないので。
PHP ではマルチバイト関数を使うために configure で –enable-mbstring を指定する必要があるということだったので、以前のサーバでは mk.conf に PHP4_CONFIGURE_ARGS を記述して configure で –enable-mbstring が指定されるようにしていました。

PHP4_CONFIGURE_ARGS+=  --enable-mbstring

ところが、pkgsrc の lang/php5 では、PHP4_CONFIGURE_ARGS に代わる変数はなく、デフォルトの configure でも –enable-mbstring は指定されていませんし、オプションで指定できるようにもなっていません。
どうしたものかと思って PHP のマニュアルやソースツリーをよく見てみると、mbstring は拡張モジュールにできるような気がしてきました。converters/php-iconv などはありますが converters や textproc などにはありません。仕方がないので find で php-* を列挙させてみることにしました。

$ find pkgsrc -name php-* -print
(略)
pkgsrc/misc/php-calendar
pkgsrc/misc/php-mbstring
pkgsrc/net/php-ftp
(略)

php-mbstring というのが misc にありました。なぜカテゴリーが misc なのかはよくわかりませんが、php-mbstring をインストールすれば pkgsrc や mk.conf を修正しなくても PHP でマルチバイト関数が使用できるようです。
ひょっとしてずっと前から php-mbstring を使うようになっていて、PHP4_CONFIGURE_ARGS を使う必要なんてなかったんじゃないかと思って、misc/php-mbstring/Makefile が import された日付を確認したら、 2004/10/31 と比較的最近でした。ちょっと安心(←何が)

Gnome の背景色

最近 Gnome (2.10.2) を使い始めたのですが、kterm とか多くの X アプリケーションの背景がグレーになってしまいました。appres(1) でみると、リソースに *background が「勝手に」追加されています。
私のところでは .xsession で xrdb -merge .Xresources を実行して、そのあとで gnome-session を exec しているのですが、gnome のほうでリソースが上書きされてしまうので、.Xresources に *background: white を記述しても有効になりません。
調べると、/usr/X11R6/share/gnome/control-center-2.0/xrdb/General.ad に設定されている内容があるようです。個人の設定としては ~/.gnome2/xrdb/General.ad を作成してそこに *background: white とかを記述すれば「Gnome のデフォルトの設定」を上書きすることができるようです。
本当は「上書き」じゃなくて「削除」したいんですけど、リソースファイルの記述だけで何とかするのは無理そうでした。gnome のセッション開始時に xrdb を動かすしかないのかな?

ssh で NetBSD 上のコマンドを実行するときの PATH

NetBSD 2.0.2 RELEASE では ssh でログインするときの PATH のデフォルトは “/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin” となっているようです。
ログインシェルが /bin/sh となっているユーザが ssh(1) 経由で xterm(1) を実行しようとして、下のようなコマンドを実行しても、通常 xterm が置かれている /usr/X11R6/bin や /usr/pkg/xorg/bin には PATH が通っていないので xterm が見つけられずにエラーになります。

$ ssh -f host.example.com xterm
xterm: not found

ユーザのシェルが /bin/sh の場合、ssh の接続先では /bin/sh -c xterm が実行されます。/bin/sh に渡される環境変数 PATH の値は “/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin” となっており、sshd の実行環境の PATH とは異なります。ところが、sshd のマニュアルにはコマンドを実行するときの PATH に関する記述がありません。
NetBSD の sshd では、コマンドを実行するときの PATH は login_cap を使用して設定しており、 /etc/login.conf を作成することで変更することができます。
/etc/login.conf がないときのデフォルトの PATH は /usr/include/paths.h の _PATH_DEFPATH (/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin) に定義されており、login_cap のシステムライブラリである libutil にコンパイル時に埋め込まれています。sshd の本体には _PATH_STDPATH が埋め込まれていますが、login_cap が正しく動いている場合には使用されません。
従って、ssh で実行したいコマンドの PATH は /etc/login.conf で設定することになります。~/.ssh/environment で設定する方法は、異なるOS環境でホームディレクトリを共有している場合に設定を切替えることができないので望ましくありません。NetBSD では FreeBSD と違い、~/.login.conf を読まないのが残念です。