Plan 9 第二版のマニュアル表紙の絵より

UNIX との違い

以下に思いつくままにUNIXとPlan9との相違点を述べる。ツールに過ぎないものの相違は省いている。(重要な論点が抜け落ちているかも知れない。)
なおUNIXに関しては多数の文献があるが、それが生まれた過程と特徴に関しては Dennis M. Ritchie による
"The Evolution of the Unix Time-sharing System"(http://cm.bell-labs.com/cm/cs/who/dmr/hist.html)
を読むのが良い。

root 特権

Plan9 には root特権は存在しない。そして root に関する全てのしがらみがPlan9では廃止された。

root のような特権ユーザがいない
chown コマンドが廃止された
SUID を廃止した
su コマンドがない (しかしこれは作れるはずである。しかし必ずパスワードが要求されるが)

「Plan9 Documents」には、管理者でさえもエンドユーザのファイルは(消す事はできるが)読む事はできないと書いてあります。しかし実は必ずしもそうではありません。もちろんUNIXのように野放途に読む事はできないのですが、Plan9のファイルサーバを立ちあげる時にノーセキュリティの状態に設定できます。この場合にはユーザ認証が行われないので読む事は可能になります。インストレーションの容易さを考えた妥協でしょうか。(最近分かりましたが、システム更新の際にユーザファイルを新システムに移行するのに必要になるのです。)

SUID なしにソースプログラムの公開とセキュリティの確保を両立させたところが巧いのですね。ここさえクリアすれば以下に述べる全ての事がらは、既存の技術の集大成に過ぎない。

ファイル

UNIXが成功を納めた大きな理由の1つに、UNIXはファイルの種類の複雑さを捨てて、ファイルに関する1つの統一した見方を打ち立てたことがある。
ファイルはバイト列である。OSはファイルにそれ以上の内部構造を与えるべきではない、と。
UNIXと言う名称はここから発生している(注釈1)。そしてファイルを木構造と呼ばれるトポロジーで結びつけたのである。この考えはシンプルにして強力であり、現代的なOSの共通した考え方になっている。

正しくは UNIX は MULTICS の反対語である。MULTICS はUNIXの開発者達も参加した大規模なOS開発プロジェクトであったが、UNIXの開発者たちはMULTICSの多数の目標の内、ファイルシステムを中心とした唯一つの事だけを十分に実現しようとした。
なお MULTICS に関しては次のWebPageが詳しい:
http://www.best.com/~thvv/multics.html
またMULTICS の解説は
F. J. Corbató and V. A. Vyssotsky:"Introduction and Overview of the Multics System"
が手頃であろう。
これらの解説を見る限り、木構造のファイル空間はMULTICSに由来する。しかしながら、ファイルはバイト列である、とする考えはMULTICSにあったのかどうかは不明である。

UNIXはデバイスもファイルとみなした。Plan9はUNIXのファイル志向を一層徹底させた。Plan9にとってプロセスはファイルである。サービスもまたファイルである。

Linuxや4.4BSDでもプロセス情報はファイルとして扱われているがPlan9はプロセス情報だけではなく、プロセスを制御する口をファイルとして持っている(/proc/*/note)。そして、
echo kill > /proc/4/note を実行する事で pid=4 のプロセスを殺せる。(Plan9には "signal" が存在しない。UNIX の signal はもうすっかり枯渇してしまっている。Plan9では数字の signal ではなく文字列を signal の代わりに使う。)

デバイスファイルも同様に制御の口を持っている。/dev/consctl はコンソールを制御するファイルである。Plan9でraw モードを実現するにはプログラムの中でこのファイルを開き単に "rawon" の文字列を書き込むだけでよい。ファイルが閉じるまで raw モードを保ち続ける。プログラムが終了すればこのファイルは自動的に閉じるから raw モードで動作するプログラムは例え異常終了する事があっても端末は raw モードになることはない。
echo rawon > /dev/consctl を実行しても端末は raw モードにならないことに注意する。なぜなら echo の実行後直ちに /dev/consctl は閉じるからである。

Plan9にとってサービスもまたファイルである。例としてPlan9のコマンド、ndb/csquery を取りあげよう。 ndb/csqueryはPlan9のネットワークデータベース(通常は/lib/ndb/local)を参照し、入力(例えば)
tcp!ar!telnet
からIPアドレスとtcpポート情報を含む出力 202.250.160.40!23 を得る。ここに ar は筆者のワークステーションのマシン名である。
csqueryのソースコードは極めて簡単で単にファイル /net/cs を開き、文字列 "tcp!ar!telnet" を書き込み、その後、/net/cs から文字列を読み取っているに過ぎない。 Plan9ではIPアドレスを知る必要のあるプログラムやライブラリ関数がこのファイルを利用している。

サービスをファイルとして実装するメリットは何と言ってもその分かりやすさである。そして全てのアプリケーションがこれを等しく参照でき、リモートファイルのマウントが可能であれば、分散環境で容易にサービスを共有できる。

名前空間

Plan9ではファイル空間の呼称を使わず名前空間(name space)の呼称を使う。ファイル空間は全てのプロセスに共通の空間であるが、名前空間はプロセス毎に見え方の異なる仮想空間である。ファイルの多重化(同名のファイルでも実体が異なる)が可能であり、名前空間の全体にわたるディレクトリの編成がユーザ権限で可能である。

ファイルの多重化のアイデアはUNIXに萌芽的に見られた。例えば /dev/tty はそのプロセスが現在使用中のttyデバイスを表しており、その実体は tty コマンドで知ることができる。 Plan9では多重化の方向がさらに徹底された。多重化にはOSが自動的に行うものもあればユーザ権限で行うものもある。/devのファイルは前者の代表格であるが、その他に/envのファイル(Plan9では環境変数もファイルであり、このディレクトリに置かれている)など多数のファイルがOSによって多重化されている。ユーザ権限で行う多重化は次に述べる bind コマンドで達成される。

Plan9 の bind コマンドは UNIX の ln コマンドとよく似ている。しかしながら ln と異なり、bind コマンドの影響はそれを実行したプロセスとプロセスグループに留まる。つまり bind は仮想的なリンクを形成する。従ってこのコマンドは ln と異なりユーザ権限でどこにでもリンクできる。既存のファイルやディレクトリに bind を適用すると、そのファイルやディレクトリは多重化される。bindコマンドによって、どのユーザも /bin や /lib のファイルを自分のファイルと置き換える事が可能になる。

UNIX の chroot() 関数はもはや不要である。chroot()関数はrootのプロセスだけが使用可能であり、ディレクトリの木構造の部分木だけにアクセス空間を限定する。それに対して Plan9 では、どのユーザのプロセスも自己の名前空間を編成でき、その自由度は正に別世界である。

Plan9の mount コマンドはサービス(/srvのファイル)をプロセスに多重化する。サービスにはファイルシステムの利用サービス、データベースの利用サービスなどが含まれる。マウントポイントは(習慣的に)サービスの種類によって異なる。例えば、
/n にはファイルシステムがマウントされる。
/netにはネットワークの接続に関係したファイルがマウントされる。
などである。

後書き
もうftpd の為に特別のディレクトリを作成する必要はないのですね。 ftpdを複数のユーザが運営している場合、Plan9では各ユーザのホームディレクトリの中にあるサブディレクトリを bind コマンドで集めて ftpd 用のディレクトリを作成できます。

ファイル属性

システムオブジェクトをファイルシステムと見なし、カーネルファイルシステムとして、それらをエンドユーザからコントロールできるようにした。
ファイル属性に、append only, exclusive access の2つを追加した
ユーザグループの意味を変更し、ユーザ毎にユーザ名と同名のグループを自動的に与えるようにした。
複数のシステムにユーザが跨がる場合、Plan9ではそれらのシステムでユーザに同一の数字IDを付与する必要はない。単に名前で管理できるようにした。
(ファイルシステムの内部では数字のユーザIDが使われている)
もちろん、SUIDビット、SGIDビットを廃止した。

メールの配送問題(UNIXでは /bin/mail に SUIDが立っている)も実に簡単な方法をとりました。マンションの郵便箱と同じ考えをとったのです。つまり、だれがここに手紙を放り込んでも構わないけど、大切な事は取られないことだ、と。Plan9ではユーザのメール箱には誰でも書き込めます。しかし append only 属性が立てられているので、誰も消せない。手紙の真偽の確認は他の方法をとればよいと考えているのですね。

WORMベースのファイル空間

Unixと比較したPlan9のファイルシステムの物理的な違いは、Plan9ではWORM(Write Once Read Many)をベースにおいて、バックアップファイルと稼働中のファイルシステムの垣根を完全にとっぱらったことであろう。あたかも一個のディスクの中に存在するように。このシステムでは過去と現在が同居している。過去のファイルシステムを見たい場合には、ディレクトリ /n/dump/ を見るだけで良い。ディレクトリ
/n/dump/1995/0315/
は 1995年3月15日のファイルシステムだ。ここにこの日の全てのファイルが見える。

ハードディスクをWORM(Write Once Read Many)ディスクへのキャッシュとして位置付けた
バックアップの考え方を根本的に変えた。毎日自動的にバックアップされ、エンドユーザのレベルでファイルを過去の状態に戻せる。

システムに多数のファイルがあっても実際には頻繁に使用されるのは一部のファイルだけである。殆どのファイルは休眠状態だ。WORMベースのPlan9ではハードディスクはキャッシュに過ぎないからハードディスクが一杯になれば使用頻度の低いファイルは自動的にハードディスクから外される。ユーザはディスクの節約を考えてファイルを消す必要もないし、消してもディスクの節約にはならない。

WORMベースのファイルシステムは非常に魅力的です。

追記型なので、データが消えないと言う絶対的な保証があること。
光ディスクなので大容量が可能である事。本来はjukebox タイプを使う。
メディアがドライブと分離可能なのでドライブが壊れてもメディアは生き残る事。

そしてPlan9の成果は正にバックアップ革命です。

多分、実際に記憶されているのは単に差分情報だけでしょうね。これをPlan9が過去のある日の完全なファイルシステムとして見せてくれているだけなのでしょう。

この技術の詳細(PS形式)

ファイルサーバ

Plan9のファイルサーバは規模と用途に応じて何種類かあります。

分散環境ではサーバ専用マシンを使用します。その場合のファイルシステム( 9fs )では、

WORMをベースとしたファイルシステム。このシステムではPlan9のバックアップメカニズムである dump ファイルシステムを利用できる。
ハードディスクをWORMの代わりに用いるpseudo-WORM。何の為にこんな使い方をするかと言えば、dump ファイルシステムを使用したいからである。
WORMもpseudo-WORMのないハードディスクだけのシステム。この場合 dumpファイルシステムは使えない。

Plan9をUNIXのように単体で使用したい場合には kfs を使う。但し、kfsのセキュリティレベルはWindow-NT程度です。 (即ち基本的にはセキュリティがない) 。従って一人だけでPlan9を使用する場合のファイルシステムです。

認証

裸のパスワードをネットワークに流すのを止めた
ユーザ認証に Kerberos 方式を採用した
マウント毎にユーザ認証を行うようにした(これは自動的に行われる)

インターネットの相互リンクでは、Kerberos方式は問題ありで、もっと進んだ方式、現在では、公開キーによる認証、ゼロ知識証明による認証などが採用されて当然です。また裸のパスワードだけが問題ではなくて、裸のデータを流さない事も重要です。これらのことはPlan9では割り切った処理をされました。(だってPlan9は研究所の内部の閉じた空間でしか使いませんから。) Plan9に続くBell研のプロジェクト Inferno でインターネットに対応したセキュリティの配慮がされています。
Inferno は既存のOSのアプリケーションとして動作するOSで、その配下で Internet 上のコンピュータの統合を目指します。Plan9 とよく似た仕組みを持ち、現在 Windows 95, NT3.5, NT4.0, Irix 5.3, Linux and Solaris 2.5.、および Plan9 の下で動作します。詳しくはInferno Home Page を参照して下さい。

	注釈:
	Kerberos に関しては
	1. W.R.Stevens,「UNIXネットワークプログラミング」(トッパン)
	2. 山本和彦,「Kerberos(1)」(UNIXマガジン, 1995.4) 
	に簡単な解説がある。(筆者は実はMITのKerberosの発表会の場にいたのである。)
	なお山本和彦氏の解説の中で Kerberos の問題点として、クライアントがサーバと
	同一の共有鍵を保有し、この管理に困ると言う説明があるが、これは Kerberos を
	UNIXのネットワークに適用したMIT方式の運用から発生する問題点であろう。
	Plan9 ではこうした問題は発生しない。
	暗号や認証に関する参考書は
	3. B.Schneier,"Applied Cryptgraphy (2nd ed.)",John Wiley & Sons, Inc
	4. D.R.Stinson,"CRYPTOGRAPHY",CRC Press
	が良著である。B.Scheierはプログラマ向けの詳しい解説、D.R.Stinsonは暗号を
	基礎からじっくりと解説している。
	5. 岡本龍明、太田和夫「暗号、ゼロ知識証明、数論」(共立出版)
	もあるが、これはよほど数学に堪能でないと読み切れないだろう。
	最近は日本語の解説本が続出で、以上の他にも本屋へ行けば多数見つかる。
	一般向けの簡単な解説は
	6. 「小特集 - ゼロ知識証明とその応用」(情報処理 Vol.32,No.6,1991)
	7. 「特集 - 暗号安全性の最近の動向」(情報処理 Vol.37,No.6,1996)