2003/03/21

カウンタ復活させようかな

せっかく検索CGIを設置したことだし、t-baseのサーバ移転直後から動かなくなってたSSIカウンタも動くようにしちゃおうかなー、といろいろ作業してたんですが。

そもそも、旧サーバからそのまま同じ設定で動かしてたはずだったのに何でカウンタが動かなくなったのか今までまったくわからなかったんですが、別にSSI自体が有効になっていない、というわけではなかったんですよね(ってか、念のため.htaccessにSSIの記述を加えてみたりもした)。で、今日検索CGIを設置したときに気がついたんですよ。ApacheでsuEXECが有効になっている、と。

SSIのEXEC機能は(<!--#exec cmd="[shに渡すコマンド]"-->ってやつ)、suEXECが有効になっていると働かないんですよね。suEXECって、HTTPデーモン側の設定ですから、ユーザ側からどうすることもできなくて、suEXECが入ってるサーバでSSI-EXECを使うためには「Webサーバ管理者にsuEXECを切ってもらう」しか対処法がないんですよね。

ここが私がsuEXECを嫌う理由わけなんですが、そもそもsuEXECはそのCGIが絶対に所有者権限で動くようになってしまい、nobodyで動かすことができなくなるわけですね。まぁ、ファイルI/Oを伴うCGIなら所有者権限で動いたほうがいいでしょうけど、それのないCGIであればnobodyで動いてた方が精神衛生上いいと思うんですよね。というのも、CGIが完璧に作られていればいいんですが、CGIに穴があったときにそれが所有者権限で動いてしまうと悪意のあるプログラムによって自分の所有する部分のファイルが破壊されてしまう可能性もあるわけですな。その点、nobodyで動いていればファイルI/Oは面倒になりますけど所詮nobodyなんでnobodyの手の及ばない部分に対する影響はある程度防げるわけですな(まぁ、nobodyのCGIがのっとられてもseteuidでEffective User IDを所有者に変えられてしまう可能性が生じるわけで、どっちにしろ穴のあるようなCGIはよろしくないんですけど)。

ちうわけで、とりあえずt-baseの管理者にsuEXECをはずしてもらうように頼もうかと思ったんですが、考えてみれば一ユーザーの一存でそんなことができるわけがないわけで(突然suEXECをはずしたりすると、現状でsuEXECに依存してた他のユーザーのCGIが動かなくなるので)、SSI-EXECを使うのはあきらめましょうかね。ちなみに、SSIのほかの機能は使えます。

ちなみに、具体的にsuEXECに依存したCGIっていうのは、CGI本体が705で、データファイルが600で、CGI内でseteuidなどで権限の切り替えをやってないという感じのCGIです。データファイルが600だとnobodyでは読み書きがまったくできない(ってことは、http経由でのアクセスができないので堅牢)わけですが、CGIがsuEXECで動いていればCGIのプロセスがファイルの所有者の権限で動くので、データファイルが600でも問題なく読めます。この場合、suEXECをはずすとnobodyでCGIが実行されるのでデータファイルを読めなくなるので、事実上動きません。

suEXECをはずしてデータファイルを600のままこのCGIを動かすにはCGI内でファイルオープン時だけseteuidで所有者権限に切り替えるか、CGIにsbitを立てる(chmod u+sしてファイル属性をrws-----xにする)か、ということになりますね。

suEXECに比べてsbitを立てたときの利点としては、実行ファイルにおいてotherにreadを与えなくてもいいんで(そのへんはWebサーバによるんですけどね)、サーバ上のシェルのある他ユーザーからファイルを読まれるとかコピーされるとかいう事がないってことぐらいですかね。それ以前に、suEXECをはずすことによってCGIの実行権限についてnobodyか所有者権限かという選択ができることが大きいんです。たぶん。よく、CGIの設置はパーミッションの設定が面倒だ(特にnobodyで実行されることによりデータファイルをotherにも読めるようにしておかないとならない、など)といわれますが、逆に実行権限を切り替えたりできるのは利点だと思うんですよ、私は。