UNIX - NFS -

1.0.0 背景
2.0.0 NFS
3.0.0 NIS, NIS+, NetInfo
4.0.0 結論
5.0.0 文献

1998/08/23

背景

ある大学では多数の WS (Work Station)が学生の為に提供されている。この大学では学生の便宜を考え、次のシステム要求を持った:
どのワークステーションを使用していても学生は同一のホームディレクトリで作業できる様にしたい。

この要求はネットワーク上にファイルサーバ(分散ファイルシステム)を持つ事によって解決できる。

NFS

UNIX の分散ファイルシステムの標準は NFS である。NFS は Network File
Sytem から採られた3文字であるが、この言葉は SUN Microsystem社による UNIX の分散ファイルシステムの実装を意味しており、この実装は現在の UNIX の標準となっている。

NFS には幾つかの問題があり、そのことが NFS の適用範囲を制限している。適用範囲を決定付けている最も大きな要因はセキュリティ上の問題である。

UNIX ホスト vega のファイルの一部を他の UNIX ホスト venus から参照できる様にするには、 vega は参照させたいディレクトリ(以下 foo とする)を venus に export し、 venus は vega の foo を import する。(具体的にはマニュアル項目 exports, mount を参照せよ)

NFS で最も問題になるのはユーザの対応関係である。
vega の /etc/passwd を

root:qk3yth3E51zjg:0:1:Operator:/home/operator:/bin/sh
news:*:6:6::/usr/spool/news:/bin/csh
alice:Eaq8Ogbk48Yuw:104:20:Alice:/home/alice:/bin/csh
bob:qKjM5IqG18qwc:103:20:Bob:/home/bob:/bin/csh</pre>

とする。他方 venus の方は

root:qk3yth3E51zjg:0:1:Operator:/home/operator:/bin/sh
news:*:6:6::/usr/spool/news:/bin/csh
alice:Eaq8Ogbk48Yuw:103:20:Alice:/home/alice:/bin/csh
bob:qKjM5IqG18qwc:104:20:Bob:/home/bob:/bin/csh

とする。alice と bob のユーザ ID が両システムで食い違っている事に注意する。
この場合には奇妙な現象が発生する。ホスト venus で alice は作業を行っているとせよ。alice は vega から export された自分の(と彼女が信じている)ファイルを編集すると実際にはそのファイルは bob のものである。つまり2つのホスト vega と venus でユーザ ID が完全に一致しないと大混乱に陥るのである。

ユーザ ID は管理主体が異なれば(一般的に言えば)異なるのである。一致させる努力をしていても異なってくる。さらに意図的に異なった ID が設定される事すらあり得る。従って管理主体が異なるホストに対して一般ユーザのファイルを export する訳には行かない。

NIS, NIS+, NetInfo

大学等の様に NFS を大規模に適用する場合には passwd 等の管理情報を一元管理しなければ混乱を生じる事がはっきりしている。NIS はそのための管理システムとして NFS と一緒に SUN によってリリースされた。NIS+ は管理の階層化を可能にした NIS の後継システムである。また NetInfo は NIS+ に相当する NEXTSTEP の管理システムである。

筆者は NIS あるいは NIS+ を使用した経験はない。しかし NetInfo の経験は持っている。以下の話の中にこうした管理システムの問題点について触れる時には実は NetInfo の経験を基にしている。NIS や NIS+ に於ても同様な問題点を孕んでいるはずである。

参考: NIS に関する解説は文献[1]に詳しい。また NIS+ に関しては文献[3]を見よ。

NetInfo(同様にNIS,NIS+)は管理情報をクライアントに持たずに運用できる。それらの情報はシステムのスタート時にサーバから供給される。クライアントは独自の管理情報を持つ事も可能であるが、それには管理者 root による設定が必要である。
クライアントがサーバ側の管理情報に依存して運用される限りに於てはクライアントの一元管理が可能である。しかしながらこの前提は以下の場合に危うくなる。

クライアントは屡々(不正常な終了の結果として次のスタート時点で)エンドユーザに root 特権を与えてしまう。(fsck を促すのである。)
PC 互換機をクライアントにしている場合にはどのユーザもシングルユーザモードで login でき root 特権を手にする事が可能である。

即ち UNIX ワークステーションをエンドユーザから保護する事は不可能に近いと言う事である。
また以下は、文献[2]からの引用である。

キャンパス内のどこからでもアクセス可能なネットワークでは、学生(または外部からの侵入者)がスパイプログラムを実行するのを防止する手だてなどなかったのである。学生がワークステーションのスーパーユーザのパスワードを盗み見したり、ワークステーションをシングルユーザモードでリブートしたりしても、手をこまねいて見ているしかなかった。

この記述は MIT(Massachusetts Institute of Technology) が NFS と NIS を導入した時(1985年頃)の経験を語っている。なお「スパイプログラム」とはパケット解析ツールの事である。このようなツールは現在では有り触れており、Window-NT や Plan9 では標準添付されている。Window95 など他の OS でも手に入る。

root 特権が手に入るとユーザはクライアントを簡単にサーバの管理から切り離す事ができる。

結論

NFS が安全に運用できるためには NIS 等の管理ツールだけでは不十分である。
以下の問題が克服されねばならない。

パスワードがネットワーク上を流れている事
ファイルサーバが認証無しにクライアントからのマウント要求を受け入れている事
クライアントがそもそも信用できない事

1 は UNIX の認証問題であり、現在では幾つかの解決策が提案されている。UNIX に於ては LOGIN 等の認証プロセスは単なるアプリケーションの問題であり、SSH の使用は有力な方向である。

2 は NFS の問題であるが根は NFS を支える基礎技術である RPC(Remote Procedue Call) における認証問題にまで遡る。RPC ではホストはクライアントが名のるホスト名とユーザ名を無条件に信じてクライアントのリクエストを実行する。この問題の解決策としては SUN の Secure RPC がある(文献[2])。

3 の問題の解決には以下の2つの課題が含まれる。即ちクライアントが信用できない環境下でも:

ファイルサーバが安全に運用できる事
クライアントを使用するユーザを保護できる事

問題の解決の為にはローカルディスクへの依存そのものを見直す必要がある。

UNIX の分散ファイルシステム改善の努力に関して文献[3]には多数の実例が紹介されている。詳しくはこの文献を参照されたい。