Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp
Aichi University
Kurozasa 370, Miyoshi-cho
Aichi, Japan

2002/02/24
Powered by Pegasus

サーバモード

サーバモードとは httpd が直接 http ポート(通常は 80 )を読み取るモードです。 サーバモードの利点は
  1. httpd が常にメモリ上にあるため、ロードの負荷が発生しない。
    (そのために、メモリを食うと言う欠点もある)
  2. httpd で書き込み処理する場合のセキュリティを向上できる。
第一の利点は一般的なものですが、第二の利点は Pegasus 固有のものです。

サーバモードで httpd を実行しない場合には listen の管理下に置かれる事になります。この場合には httpd はユーザ none として実行されます。CGI で書き込み処理が必要な場合には、そのファイルはユーザ none による書き込みを許可しなくてはならなくなります。ファイルサーバが共同利用の場合には許されない選択になる事が多いでしょう。

Pegasus のサーバモードは指定したユーザとして httpd を実行する機能を持っています。httpd がユーザ web として実行できるならば、次のようにすることによって、共同利用の環境下でもセキュリティが保たれます。

ユーザ alice が
/usr/alice/web/doc/data
に対して、alice 自身と httpd からのみ読み書きを許したいとします。この場合には、
/adm/users

alice:alice:web
web::
のようにし、認証サーバにユーザ web を登録します。(alice はユーザ web をグループメンバとして認めたのですから、大切な alice のファイルにはグループ書き込みを禁止しておいた方が無難です。)

alice は CGI を通じて読み書きの発生するファイルに対して

chmod 664 /usr/alice/web/doc/data
のようにグループ書き込みを許します。httpd 以外に誰もユーザ web のプロセスを発生できなければ、目標が達成されたことになります。

	注釈: もしも alice のグループに web を加えるのが嫌であれば
	alice_web:alice:web
	で新たなグループを作成し、CGI からの書き込みを許すファイルを
	--rw-rw---- alice alice_web ....
	にしたらよい。(必要なら lock も)

このシンプルな方法は Pegasus だからこそ採用できる事に留意して下さい。 なぜなら他のサーバでは他人の CGI (これもユーザ web で実行される)が alice の /usr/alice/web/doc/data に対するアクセス権を持っています。従ってこのやり方は意味を持ちません。
しかし Pegasus はユーザごとにサービス空間を綴じ込めるので、他人の CGI は /usr/alice/web/doc/data にアクセスできません。


Pegasus は、httpd を起動したユーザの ID でサービスを行うオプション(-u)を持っているので、httpd を手動で起動する場合には auth/login で一旦ユーザ web になればよいだけですが、起動時に自動化する場合にはどのようにすればよいでしょうか?

Pegasus には、この目的のためにツールとして monが付属しています。 これは Pegasus を指定したユーザの ID として立ち上げ、かつ次に述べるセキュリティ上の問題を解決するためのモニターです。


セキュリティ

CGI で任意のプログラムを実行する事を許した場合には、様々な事を考えておく必要があります。仮に悪意のユーザが存在した場合の事を考えてみましょう。CGI プログラムを通じて、httpd を殺す事によるサービス妨害、さらに運用中の httpd を他のものに置き換えると言うさらに危険な問題が発生する事まで考慮する必要があります。

注:ユーザ none の下でサービスを行う場合には CGI プログラムは 他の none のプロセスを殺せません。 (殺せるようならカーネルのバージョンを上げて下さい。)

httpd のオプション -m を付けない限り CGI はマウントを許可されません。
マウントオプションが無い場合に pegasus は CGI を実行する前に /net の使用を不可にし、以降のマウントを禁止します。この場合に CGI は外部ネットワークとの通信を遮断され、snoopy の実行はもちろん 通信ポートへのあらたなアクセスができなくなります。従ってポートにアクセスするプログラム、例えば httpd を実行しても失敗に終ります。
それでも、運用中の httpd を殺す事は可能です( CGI と httpd は同じユーザ ID で実行されている事を思い出して下さい)。mon はこうした事態に対する簡単な対策です。

mon をユーザ web として実行してはなりません。mon のプロセスがユーザ web のものでない事が、CGI から mon を守っている事に注意しましょう。

問題の発生原因となっている CGI を確定する方法を持つ事が、こうした行為に対する最大の抑止力です。mon のログと httpd のログを付き合わせると、問題の CGI が分かります。

mon が想定するような悪質なユーザが現実的な問題になるかは妖しいのですが、mon を使用する事によって httpd のアップデートとが簡単になる利点があります。