現在、どのユーザとしてマシンを使用しているかを知りたい場合には、
UNIX と同様に Plan9 においてもプロセスのオーナーは、自分のプロセスにアクセスでき、制御できる。例えば実行中の自分のプロセスを落とすことができる。
Eve プロセス: このネーミングはPlan9 のセキュリティモデルを説明する用語として Plan9 第三版の途中から使用された。
none は UNIX の nobody に相当する。Plan9 では多くのネットワークサービスがユーザ none のプロセスによって行われている。ユーザ none のプロセスはいわば Eve プロセスのエージェントであるから、Eve だけが none を生成できるとするこの考えは当然と言える。
Plan9 ではいかなるプロセスも認証サーバの認証を受けずに他のユーザのプロセスに変身できない。(Eve が none に変身するのは唯一の例外である。)
認証を受け、他のプロセスに変身する手順は、第三版の殆どの添付プログラムでは、
一旦 none になって、それから変身している。(また、そうあるべきではないかと思える。)
auth/login
はこの点では例外的である。ソースコードを読む限り、none を経ないで変身している。
最近、久しぶりにカーネルを更新して見ると none のプロセスの特性に関して重要な変更が行われた事に気が付いた。これまでは none のプロセスは none のプロセスに干渉できた。none のプロセスはシステムのエージェントである事を考えると、これは潜在的なセキュリティ上の問題をはらんでいた。これに手が打たれたのである。
UNIX と同様にファイルのオーナーはプロセスのオーナーと密接な関係を持っている。しかし完全に同じではない。
UNIX に於てはプロセスのオーナーがファイルのアクセス権を定める。しかしこの事が
UNIX のNFS(Network File System)が旨く機能しない理由になっている事に注意する
必要がある。
ファイルサーバをマウントするクライアントを考えよう。クライアントはエンド
ユーザの手中にあり、その OS を信頼できる保証は無い。例えばパッチが当てられてお
り、その OS は任意のユーザのプロセスを自由に生成できるようになっているかも知れないのである。こうした事情があるために NFS に於てはその利用範囲が厳しく限定されるのである。
分散するコンピュータが1つの名前空間の下に安全に相互接続される為には、ファィルへ
のアクセス権をプロセスの所有権に基づいて定める事はできないのは明らかである。
Plan9 ではパスワードに基づく認証だけがファイルへのアクセス権を手にする道である。
ファイルシステム毎にユーザ登録する事、それらの間にユーザ ID が一貫性を持つ必要が無い事は分散ファイルシステムにとって本質的であり、UNIX と Plan9 が大きく異なる点である。そしてファイルサーバはマウント時にマウント要求を行ったユーザの正当性を確認するのである。従って認証サーバの認証を受けた事がマウント要求を行ったファイルシステムへのアクセス権を持つ事は保証されないのである。
ファイルシステムに登録されていないユーザのマウントを許すか否かに関して、Plan9 のポリシーは明確ではない。常識的には許すべきではないと考えられる。そして、Plan9 の本来のファイルサーバはこの方針を貫いているように思える。
Plan9 の Eve のプロセスは、UNIX の root と異なり、通常はファイルの許可ビットに従う。Eve のプロセスは次のコマンドでファイルのアクセス制限を無視するモードに入る事ができる。
問題が生じないか....
none のプロセスは他のマシンの none のプロセスを落とせない。即ち、実行されるマシンが異なれば、異なる none のプロセスとして扱われている。(これは第二版においてもそうだったような気がする...)
第三版の現在のリリースではファイルへのアクセス権に関して次のようになっているように思える:
none のプロセスが none のファイルにユーザ none としてのアクセス権を持つのはローカルサーバ(kfs)に対してだけである。
CPU サーバや Plan9 端末がネットワークサービスを行う時には none のプロセスが使用される。Plan9 端末の none のプロセスが他のマシンが管理する none のファイルを書き換える事ことができるのであろうか?
筆者はこの問題について幾つかの実験を行ったが書き換えはできない。others に対してファイルの生成を許しているディレクトリにファイルの生成を行った場合に none をオーナーとするファイルを作る事ができるだけである。
none のプロセスの権限に関する Plan9 のこの考え方は現在のリリースのものである。この問題に対するポリシーは Plan9 のドキュメントからは読み取れない。従ってまだ実験的なレベルであり、今後変更を受ける可能性がある。
筆者にはファイルのアクセス権に対する現在の none の扱いはもう少し緩めても良いように思える。CPU サーバで実行される none をファイルサーバ(fs)は信頼しても良いのではと...ps コマンドあるいは
cat /dev/user
を実行すればよい。
Eve のプロセス
Plan9 では(UNIXと異なり)、マシンを立ち上げたユーザのプロセス(Eve プロセス)がそのマシンのハードウェアを制御する。Eve プロセスは UNIX で言えば root プロセスのような存在であるが、その権限はそのマシンの外には及ばない。
none のプロセス
Eve プロセスだけがユーザ none のプロセスを生成できる。none のプロセスの生成には認証はいらない。
none のプロセスは、none の生みの親である Eve プロセスだけがコントロールできるとするのが正しい考え方である。
筆者はこれまでは none のプロセスを落とすために、 none になるためのプログラム su を作成し使用していたが、もはやこれは使えない。新しいカーネルでは、 Eve は(pid=1234を落とす場合には)
chmod 664 /proc/1234/ctl
echo -n kill >/proc/1234/ctl
で落とす事になる。(2002/03/10 追加)
プロセスのオーナーとファイルのアクセス権
ユーザのファイルのアクセス権はコマンド ls -l によって知ることができる。例えば、
cpu% ls -l
d-rwxrwxr-x M 51334 arisawa alice 0 Nov 10 2000 T
d-rwxrwxr-x M 51334 arisawa arisawa 0 May 27 16:53 Y
--rw-rw-r-- M 51334 arisawa arisawa 984 Apr 27 10:04 u
Plan9 のファイルには UNIX と同様にファイルのオーナー、ファイルの所属グループの概念が存在し、owner, group, others に対するアクセス許可をフラグで指定し、UNIX と同様な意味を持っている)
プロセスのオーナーとファイルシステムへのアクセス権
ファイルシステムには個々にユーザを登録する。即ち、個々のファイルシステムはファイル
/adm/users
の中にその利用者を登録している。この内容は例えば次のようなものである。
-1:adm:adm:
0:none:adm:
1:tor:tor:
2:glenda:glenda:
9999:noworld::
10000:sys::
10001:upas:upas:
10002:bootes:bootes:
3:alice:alice:
各行の最初の数字はユーザ ID であるが、(UNIX のファイルシステムと異なり)この数字はファイルシステム毎に異なっていても構わない。
他方簡易ファイルシステムである kfs は登録されていないユーザのマウントを許している。その場合には、任意のユーザ名で kfs ベースの Plan9 端末を立ち上げる事が可能である。そのユーザが kfs の /adm/users に登録されていない場合には、そのユーザは(プロセスのオーナーはそのユーザの名前であるが)ファイルへのアクセスに関しては none として振る舞っている。(筆者には、拒否しても良さそうに思えるが...)
Eve のプロセスとファイルのアクセス権
Eve のプロセスは、ローカルディスクへの無制限のアクセス権をもっている。但し UNIX の root のように質は悪くは無い。root に比べて簡便さと安全性を兼ね備えている。
disk/kfscmd allow
このコマンドは Eve が支配するローカルのディスクに対してのみ発行できる。
none のプロセスとファイルのアクセス権
none のプロセスは Eve のエージェントとして働いている。そしてどのマシンの Eve も none のプロセスを生成できて、どのファイルシステムにもユーザ none が存在する。
なにしろ、現状ではローカルファイルサーバ(kfs)を使用しない限り none だけが書き込み可能なファイルを実際上作れない。
!