グループ編成
目次
2013/02/13 改訂
Plan9 のユーザ管理は管理ファイル /adm/users に基づいて行われる。
/adm/users
ここでは Plan9 のファイルサーバである cwfs と fossil のファイル管理の考え方と /adm/users の形式について述べる。現在の Plan9 には簡易ファイルシステムである kfs も残っているが、管理ファイルの形式に関しては kfs は cwfs と同じである。
ユーザとグループ編成の状態は /adm/users を見れば分る。このファイルの各行は次の形式である。
ID:name:leader:members
ID の扱いは cwfs と fossil とでは異なる。cwfs では数字であるが、fossil では文字列である。いずれもファイルシステムの内部で使用されているファイルの所有者を表す識別子である。ID の形式の違いを別とすれば、基本的な考え方は cwfs と fossil の間に違いは存在しない。
name はユーザ名であり、どのユーザもそのユーザと同名のグループを持っている。members はグループの構成員である。構成員のリストはコンマで区切る。
以下、特に断らなければ cwfs に基づいて解説する。
例えば、
3:alice:alice:のような行があれば、この cwfs に於ける
alice の ID は 3 であり、ユーザ alice とグループ alice の存在が許されている事が分かる。グループ名 alice の存在は1番目の alice から分かるのであって2番目の alice からではない。2番目の alice は alice のファイルのグループアクセス権の設定権者を表している。このケースではグループ alice にはユーザ alice 以外のメンバはいない。
ユーザ名には
`?', `=', `+', `-', `/', and `:'を除く任意の印字可能文字が使える。
ユーザ alice が所有するファイルには "alice" の ID が振られている事が1番目の alice から分かるが、この数字はファイルシステムの内部の話であって、これが問題になるのは特殊な場合であろう。
alice:alice:alice:のように書く。先頭の
alice は単なる ID であり alice である必要はない。
alice はユーザ名と考えてもよいしグループ名と考えてもよいことが分かる。例えば
10001:alice:bob:bob,carolとなっていれば
alice には alice と bob と carol が属している。
- この場合
bobとcarolはaliceグループに属するファイルのグループパーミッションに従ってファイルの読み書き実行が可能になる
bobもcarolもchgrpコマンドでaliceグループのファイルを作成できる。
bobはグループaliceのリーダであり、aliceグループに属すファイルのパーミッションを変更できる。
もしも
10001:alice::bob,carolとなっていれば、この場合はグループリーダーがいないのではなく、
bob も carol も等しくグループリーダとしての権限を発揮できる。
グループリーダはグルーブアクセス権を変更できるのだからファイルの死命を制することになる。alice が自分のファイルを守る必要があるなら
10001:alice:alice:bob,carolとしなければならないだろう。
/adm/users を覗いてみると、グループリーダにユーザ名が指定してされていないユーザが存在するが、いずれも通常の意味でのユーザではない。
さてエンドユーザの立場からすると、現実社会の組織の階層性を反映した、SE の世話にならない、エンドユーザ主導のグループ編成を可能にして欲しいのである。
UNIX のグループはエンドユーザにとって殆ど役に立っていない。Plan9 においてはユーザは少なくとも1個の固有のグループを持ち、いくらか改善はされている注1。しかしながら、その固有のグループにメンバを追加するコマンドが準備されているわけではない。(そのようなコマンドを作ろうと思えば、カーネルの改造なしに可能であろう。)
Plan9 は UNIX ファイルシステムとの互換性を重視した。そしてその範囲内で、現実的なレベルで新たなグループ編成の考え方を打ち出したのであある。
Plan9 で想定されているグループ編成は例えば
20001:staff:bob:alice,bob,carolのようなものである。
staff はユーザ名と言うより実際には単なるグループ名であり、そのリーダは bob で、全権を任せられているのである。(bob はメンバを決定する権限を持つべきであるが Plan9 ではそのようになっていない。)
以上のように考えると /adm/users はユーザを記述しているファイルと言うより、グループを記述しているファイルであると言える。ユーザ管理とグループ管理との間に本質的な区別は不要であるとの主張であろう。
コンソール
ファイルシステムへのユーザの追加や削除は、ファイルサーバのコンソールから行われる。
/adm/users の内容を編集して、ユーザの追加・削除などは(アクセス権さえあれば)可能ではあるが、ファイルサーバのコンソールからの操作、例えば cwfs の場合には
echo users >> /srv/cwfs.cmdを行なわない限りファイルサーバの動作に影響を与えない。
Plan9 ではパブリックサービスは CPU サーバが行っており、通常はファイルサーバが前面に出る事はない。
cwfs も fossil もファイルサーバから動作中のファイルシステムへ管理に関した要求を出す事ができる。この方法には2つある。1つは先に挙げた
echo DEMAND >> /srv/FSCONSのような方法である。
FSCONS は cwfs の場合には cwfs.cmd、fossil の場合には fscons である。DEMAND は、ファイル管理関する多様な要求があり、詳しくはマニュアルを読む必要がある。
FSCONS と会話的に要求を出す事もできる。その場合には
cwfs の場合には
con -C /srv/cwfs.cmdfossil の場合には
con /srv/fsconsである。
cwfs と fossil では考え方が多少違う。cwfs は echo を使う事を想定しているらしい。そのために con を使った場合にプロンプトを出さない。他方、fossil では con を使う事が想定されている。
echo を使った場合の出力メッセージは
cat /srv/cwfs.cmdでモニターできる。同様な事は fossil の場合にも可能なはずである。
デバッグなどのメッセージは標準エラーに出される事が多いので、その場合には
cat /dev/kprintを実行しておいた方が良い。
両者の使い方の違いは、特権モードのサポートの仕方にあると思う。cwfs は
allow要求を持っており、あらゆるパーミッションチェックを無効にする。このような危険なモードを持つのは、特権モードはシステム構築時に不可避だからである。しかも
allow はファイルにアクセスする全てのユーザに特権を与えてしまう。
他方、fossil はもっと穏便であり、特定のユーザ(ファイルサーバのオーナー)にだけパーミッションチェックを無効にしたサービの口を出す事ができるようになっている。
さて僕は、web などのサービスを止めないでファイルのメンテをやりたい。そのためには安全な allow が不可欠である。そこで cwfs に対して
allow arisawaのような要求が可能なように修正を行った。
Plan9 の特権モードはカーネルにあるのではなく、ファイルシステムの側にある事に注意しよう。また UNIX ではファイルシステムはカーネルと一体であるが、Plan9 ではファイルシステムはカーネルとは独立したユーザー空間で動いている事に注意しよう。そのために、Plan9 では UNIX のような特権ユーザ root は存在しない。ファイルシステムに許された任意のユーザが、(一時的に)ファイルシステムへの特権を持てるのである。