コンセプト

• 1.0.0 ドキュメントの管理主体に基づく名前空間の分離
• 1.1.0 通常の web のサーバ
• 1.2.0 Plan9 の標準 web サーバによる進展
• 1.3.0 Pegasus によって実現された web サーバの名前空間
• 2.0.0 Pegasus における名前空間の再編成
• 3.0.0 ファイルのアクセス保護
• 3.1.0 CGI wrapper
• 3.2.0 9.2.u と v9fs
• 4.0.0 自由度の高い仮想ドキュメント環境

2002/11/29 更新

ドキュメントの管理主体に基づく名前空間の分離

通常の web のサーバ

通常の web サーバではサーバルートはアクセス制限に対して何の意味も持っていません。この事は CGI を使用した場合に直ちに問題になります。即ち web のサーバは一見するとクライアントからのアクセス可能なファイルを制限しているように見えても、CGI プログラムからはシステムの全てのファイルが見えてしまいます。この事は重大なセキュリティ上の問題をもたらしかねません。そのためにエンドユーザによる CGI の使用は禁止されるかあるいは厳重な統制下に置かれるのが普通です。

図1: 伝統的な web サーバの名前空間
real space = service space

ドキュメント空間( document space )は web ページを構成するファイルの集合です。alice のドキュメント空間はブラウザからは /~alice でアクセスされるファイルの集合です。サーバ上には様々な人々が作成するドキュメントがありますが、これらはサービス空間の中にあるので CGI からは隠されていません。

Plan9 の標準 web サーバによる進展

図2: Plan9 の標準 web サーバで実現された名前空間
real space > service space

Pegasus によって実現された web サーバの名前空間

一般に1つのサーバ(some.dom.com)には様々な人々が作成する web のドキュメントが存在し、それらはサーバにおけるそれらの人々の位置付けに従って次のようにいろいろな方法でクライアントからアクセスされます。

	http://some.dom.com/pathname	# 実ホストのドキュメント
	http://some.dom.com/~alice/pathname	# ユーザドキュメント
	http://other.dome.com/pathname	# 仮想ホスト(IP が異なる)のドキュメント
	http://virtual.dom.com/pathname # 仮想ホスト(IP が同じ)のドキュメント

この問題は図3a、図3b に示すように、サービスを行う web のサーバが、ドキュメントごとの名前空間の中でサービスを行うことによって解決されます。そしてこれは Pegasus によって初めて解決されました。

図3a	図3b

ドキュメントの管理者ごとに独立した名前空間が与えられる必要がある
図3a は {alice} のドキュメントをサービスしているときの Pegasus のサービス空間
図3b は {bob} のドキュメントをサービスしているときの Pegasus のサービス空間である

Pegasus における名前空間の再編成

• alice を実ホストのユーザ
  
• bob を実ホストの web ドキュメントの管理者
  
• carol を仮想ホスト(名前を car としましよう)のドキュメントの管理者とします。
  

http://car	*/usr/carol/www
/		*/usr/bob/www

/~alice		*/usr/alice/web

そしてシステムの管理者(たぶん bob でしょう)は /lib/namespace.httpd で web サーバのサービス空間を定義します。するとクライアントからアクセスがあるたびに、このサービス空間の中に、要求があったドキュメントの管理者のファイルだけが、マージされます。その結果クライアントから alice のドキュメントに要求があった場合には図4に示されるサービス空間とドキュメント空間が実現されます。(但し、この図では /lib/namespace.httpd による編成部分は省略されています。この部分は薄い灰色の領域に含まれます。)

図4. Pegasus で実現された web サーバの名前空間
ドキュメントの管理者ごとに独立した名前空間が与えられる

ファイルのアクセス保護

1. サーバをユーザ web として実行する。
   ただし web は実際のユーザではありません。(従ってファイルを所有する必要はありません。)
   
2. /adm/users に alice のグループメンバとして web を追加する。即ち、
   alice:alice:web
   
3. alice は data のアクセスモードを
   --rw-r----- alice web .... data
   に設定する。
   

UNIX における救いは、この問題の解決の必要性を認識し、解決しようと努力している人々が存在することです。2つのアプローチを紹介します。

CGI wrapper

UNIX の CGI wrapper と Pegasus とを比較すると Pegasus の方が安全性が高いと言えます。CGI wrapper では下手な CGI を作ると、そのユーザの全てのファイルを危険にさらします。Pegasus ではユーザ web に対して書き込みアクセスを許しているファイルだけが危険にさらされます。(Windows ではシステムの全てを危険にさらす!)
管理面でも Pegasus の方がはるかに簡単です。管理者側から一切の管理が必要ありません。単にユーザ web として httpd を実行すればよいだけです。そして CGI はどこにおいても構いません。

9.2.u と v9fs

自由度の高い仮想ドキュメント環境

Pegasus は仮想ドキュメント環境を実行ハンドラによって実現します。 CGI は実行ハンドラの特殊な設定にすぎません。実行ハンドラの内容の設定は完全にドキュメントの管理者に任せられているので、彼らは自分たちのニーズに応じた内容を盛り込むことができます。

実行ハンドラとはリクエストされたファイルのパスパターンに応じてその処理を行うプログラムの事です。実行ハンドラは Apache などでは、httpd.conf の中で可能な設定の一覧がリストアップされ、その中からコメントを外すことによってしか選択できません。Apache/1.3.27 の場合については以下の5つです。

# AddHandler cgi-script .cgi
# AddHandler server-parsed .shtml
# AddHandler send-as-is asis
# AddHandler imap-file map
# AddHandler type-map var

# path      　　　　 mimetype    unused  execpath arg ...
/netlib/*/index.html text/html     0 　　/bin/ftp2html
*.http                  -        　0     $target
*.html      　　　　 text/html     1     $target
*.dx_html   　　　　 text/html     0     /bin/dx $target

特殊な拡張子のファイルあるいは特殊な場所にあるファイルに対して特殊なプログラムで処理する事もできます。Server Side Include の機能も実行ハンドラを使用して実現できます。また、 FTP サーバのようなサービスをweb サーバで代行する場合にはファイルの一覧をクライアントに示す必要があるでしょう。このような場合には FTP 用のファイルが置かれているディレクトリに対して自動的にファイルの一覧を表示するプログラムを実行させるようにします。

Pegasus の実行ハンドラの考え方は広い応用を持つ事が想像できますが、ドキュメント管理者にこれだけの自由が与えられるのは、ここでの設定が、他人のドキュメントに影響を与えないからです。