Namespace
目次
- 2001/06/09 校正
- 1998/09/05 全面改訂
- 1998/06/02
H2: 名前空間
UNIX は Multics と比較され、何も新しい発明はないと言われる事がある。UNIX の開発者たちが OS に関して確かに新しいアイデアを出したとすれば、それは Plan 9 の 名前空間(namespace)であろう。
ファイルは名前とその内容とアクセスメソッド(open,close,read,write...)で特徴付けられる。UNIX のファイルシステムは名前を木構造のトポロジーで結びつけた。UNIX では名前のなす空間を名前空間と呼んでいる。UNIX に限らずこれまでの全ての OS (オペレーティングシステム)では、そこで動作している全てのプログラム(プロセス)は同一の名前空間を見る。
Plan 9 の名前空間はプロセス毎に編成可能な私的な空間である。どのプロセスも自分の名前空間を編成できる。この名前空間は他のユーザに影響を与えない完全に私的な空間である。サーバは名前空間の部分木を提供する。ユーザはサーバによって提供される部分木を寄せ集めて、自己の好みに合わせて 1 個の木を作る。これが Plan 9 の名前空間である。
BIND
Plan 9 の名前空間の編成はたった1つのコマンド bind でやっていける。
例に基づいて説明しよう。Plan 9 では
/binは空のディレクトリである。システムの実行ファイルは CPU の種類毎に
/386/bin /sparc/binの様に CPU 名で始まるディレクトリに置かれている。またシェルスクリプトは
/rc/binに置かれている。ユーザ alice もまた個人の実行ファイルを持ち、それらは
/usr/alice/bin/386<br> /usr/alice/bin/rc<BR>に置かれている。
alice が login すると
bind /386/bin /bin bind -a /rc/bin /bin bind -a /usr/alice/bin/386 /bin bind -a /usr/alice/bin/rc /binが実行され、これによってユーザが必要とする実行ファイルを全て /bin に集められる。bind のオプション -a は「後に」の意味である。つまり同じ名前が存在した場合の優先度を後に持って行く。これとは逆のオプション -b も存在する。さらにもう1つのオプション -c が存在し、このオプションを付けない限りバインドされたディレクトリにファイルは生成されない。
bind の機能によって PATH を設定する必要がなくなっていることにも注意しよう。
ファイルの置換
bind の -b オプションはファイルあるいはディレクトリを置き換える。ユーザの権限でデバイスファイルですら仮想的に置き換える事ができるのだ。Plan 9 ではこのオプションが巧みに利用されている。
典型的な例が
/dev/consである。これは UNIX の /dev/tty に相当する。但し UNIX と異なり Plan 9 にはこの他にコンソールデバイスは存在しない。アプリケーションは /dev/cons から文字を読み取り /dev/cons に書き出す。明示的に /dev/cons をオープンしなくても、ファイル記述子 0, 1, 2 が /dev/cons と結びついている。
/dev/cons はそのままでは文字だけを扱うデバイスである。Plan 9 のシステムに UNIX から login した場合にはこの状態の /dev/cons を使用する事になる。
Plan 9 のウィンドウマネージャーはユーザに新しい /dev/cons を提供している。カーネルの提供する /dev/cons に新たな機能の付加サービスを行い、その結果を再びアプリケーションに提供するのである。
もしも UNIX でデバイスに機能を付加しようとすればカーネルの内部コードを変更するかデバイス名を変更するかしなければならない。前者は極めて困難かつ危険な作業であり、後者を採れば新しい機能を利用する全てのプログラムを変更し再コンパイルが必要になる。いずれも現実性がないのである。(従って実際には個々のプログラムの内部で個別に対処されるであろう。)
Plan 9 のアプローチは圧倒的に優れている。どのプログラムも修正は必要なく、ユーザもこれまでと同じ様に操作をすればよい。機能だけが向上しているのである。
サービスプログラムの実行空間
bind の他の重要な応用例はサービスプログラムの実行空間の制御である。
Plan 9 では公開されたサービスプログラムは限定された名前空間の中でサービスを行なう事ができる。これによってセキュリティを格段に高める事が可能である。
Plan 9 がアクセス空間を限定する方法は UNIX の Web サーバがアクセス空間を限定する方法と本質的に異なっている。UNIX の Web サーバは自身の工夫によって公開する名前空間を限定する。この限定は CGI スクリプトには及ばない。従って CGI スクリプトの作成者も自らの工夫によってアクセス空間を制御せざるを得ない。(しかしながらエンドユーザが作成する CGI スクリプトはサーバに載せられないほど危険であろう。)
他方 Plan 9 ではサービス空間を根本的に限定する事が可能である。Web サーバは始めから OS の機能によって限定された空間の中でサービスを行い、CGI スクリプトもまたそうである。不注意なプログラムによる被害はサービス空間の外へは及ばない。
サービス
OS はユーザに様々な形態でサービスを行っている。- カーネルの窓口サービス(システムコール)
システムコールへの利用はプログラムを介して行う。date や ls など
UNIX にはシステムコールをユーザに仲介する多数のプログラムがある。
- ユーザには扱いにくいファイルを扱い易い方法で提供するサービス
データベースのサービスが典型であるが、man などもこの部類に属する。
- ネットワークを介して遠方のコンピュータにアクセスを許すサービス
nfs, ftpd, httpd などがこれに属する。
Plan 9 が様々なサービスをファイルとして提供しているのにはいくつかの理由がある。
第一に、ファイルへのアクセスは初等プログラマでも知っている。open, read, write,close などの決まり切った初等的なアクセスメソッドで全て統一できる。
第二に、サービスへのアクセス権はファイルへのアクセス権で代用できる。
第三に、ファイルをネットワークを通じて提供する技術は確立している。
ネットワークサービスがファイルの I/O として提供されれば、ネットワークサービスを利用するプログラムが極めて簡単になる。このようなプログラムは現状ではネットワークの知識無しには書けない。そしてネットワークプログラムは難しいのである。
Plan 9 は全てのサービスをファイル I/O として提供するので唯一つのプロトコルがあれば足りる(注)。このプロトコルを 9P と呼んでいる。サービスへのアクセスは多くの場合には特別のソフトウェアを必要としない。読者はリモートファイルシステムへのアクセス方法として、 ftp の原始的なプロトコルと NFS の高機能なプロトコルの使い勝手を比較してみるのがよいだろう。
ファイルとして扱われるサービスは、プロセス間の通信やプロセスの制御に及ぶ。その結果 Plan 9 は遠く離れたコンピュータ相互のプロセス間の通信や制御を初等的な方法で可能にするのである。
カーネルのサービスもファイルの I/O として提供され、名前空間に組み込まれる。Plan 9 は UNIX がシステムコールとして扱っていた多数の情報をファイル I/O として扱いシステムコールが 38 個に激減してしまった。FreeBSD のシステムコールが 200 個余りもあるので如何に多数のシステムコールが整理されたかが分かるであろう。
MOUNT
mount コマンドはサーバが提供するサービスをファイルとして名前空間に追加する。サーバはローカルコンピュータによるものでもリモートコンピュータによるものでもいずれでも構わない。但し、サーバはファイルとして利用可能な形態でサービスを提供する必要がある。UNIX の世界では NFS などのサービスがマウントの対象となる典型例である。ファイルシステムのマウントは分散化されたシステムの統合において中心的な位置を占めている。
UNIX ではマウントは管理者にのみ許される。そしてマウントの影響は全てのユーザに及ぶ。( NFS の場合にはさらに問題が多く、たぶん書き込み許可は与えられないであろう。事実上機能不全に陥っているのである。)
Plan 9 ではマウントはサーバに対してアクセス許可を持つ全てのユーザに許される。Plan 9 ではこの自由度の御蔭で、分散配置された多数のコンピュータの名前空間を、ユーザの好みのままに、あたかも1つのコンピュータの名前空間の様にアレンジする事ができるのである。Plan 9 においてこの事が可能なのは Plan 9 のマウントは純粋に私的な行為だからである。即ち、マウントされたファイルは他のユーザからは見えない。この事は分散配置されたコンピュータを統合する場合に本質的な問題である。
Alice はファイルサーバ vega と venus のユーザだとしよう。UNIX ではエンドユーザである Alice はマウントの権限を持たないが、仮に様々な工夫(例えばSUID を無効にするとか..)によって権限を持てるようになったとしよう。その場合にも以下のような問題が発生する。
Alice が vega にマウントした venus のファイルを他のユーザにも見られた場合に困らないか? venus は機密のデータを持っていて、Alice は venus へのアクセスを許された特殊なユーザかも知れないのである。(分散化の動機は屡々セキュリティ上の要請と密接に関わっている。)
Alice は vega の他のユーザに見られることなく venus のファイルシステムをマウントする必要があり、 Plan 9 はそのようなマウントの方法を採用しているのである。
リモートアクセス
Plan 9 はリモートホストのアクセスに関して以下の事を実現してくれる。- ローカルホストと同一のユーザーズインターフェースを提供する。
- ローカルホストと同一のファイルシステムを提供する
- ローカルホストで作成したプログラムがそのままリモートホストで実行できる。
(逆もまた可能。)
UNIX ユーザはリモートホストで作業を行いたい場合には telnet (あるいは rlogin )を使う。この場合リモートホストはローカルホストに比べ操作性が極端に落ちる。従って敬遠される。
UNIX のユーザは自分のワークステーションのファイルシステムを高性能な CPU を持つリモートホストにマウントできない。またその逆も実際上は許されていない。従って2つを使い分ける場合にはファイル転送に頼らざるを得ない。このようなことは面倒なばかりか、ユーザにファイル管理上の大きな負担を押しつける事になる。
Plan 9 ではコマンド cpu がユーザをリモートホストへ接続してくれる。UNIX と異なり、Plan 9 ではユーザから見たリモートホストはローカルホストと基本的に同じである。 シェルを使う時のプロンプトの違い、フロッピーディスクを使う時の意味するものの違い、ps コマンドによって表示されるプロセスの違い、など幾つかの違いは存在するが、利用者インターフェースやプログラミング環境などは完全に共通である。では何故リモートホストを使うのか? 高性能な CPU を使いたいからである。
Plan 9 においてはリモートホストで見えるファイルシステムと自分のワークステーションで見えるファイルシステムの間に基本的な違いはない。リモートホストのファイルシステムはワークステーションからマウスを使って編集できる。リモートホストの CPU はワークステーションのファイルをもコンパイルし実行できるのである。このプログラムがグラフィックスを扱っていても、その結果はワークステーションのウィンドウに表示してくれる。(ウィンドウもファイルであり、リモートホストにマウントされているからだ。)