要約

  • Amoebaのcapabilityは、48ビットのサーバーポート、24ビットのオブジェクト番号、8ビットの権利、48ビットのチェックフィールドから成る128ビットのベアラー参照だった。
  • サーバーによる受理は、現在の検証規則の下でトークンが有効で、要求操作が権利ビットの範囲内だと示す。人間の身元、組織的な承認、目的、外部効果の完了や永続性は別の証拠を要する。

128ビットの中に「誰」はいなかった

Amoebaのクライアントプロセスは、操作のたびに中央の権限管理者へ自分の名前を照会させるのではない。capabilityと操作要求をサーバーに渡す。サーバーポートが要求をサービスへ導き、オブジェクト番号がそのサービス内の対象を選び、権利ビットが要求できる操作を限定し、チェックフィールドが不正な書き換えを見破る。

この四つのフィールドに、人物名はない。

それは未完成な設計の穴ではなく、分散システムとしての選択だった。Amoebaではユーザープロセスがcapabilityを保持し、複製し、別のプロセスへ送れる。権限は参照とともに移動し、サーバーは人物伝ではなく、提示された参照と要求された操作を検証する。中央カーネルが全capabilityの所持者を記録し続けなくても、各サーバーは自分のオブジェクトを保護できる。

この仕組みが答えるのは、狭く重要な問いである。「この有効な参照の所持者は、このサーバー上のこのオブジェクトに、この操作を要求できるか」。一方、「所持者は組織上の誰か」「その人物は今回の目的について承認を得たか」「操作の後に期待した現実の結果が起きたか」は、同じ問いではない。

四つのフィールドは、それぞれ別の仕事をした

1986年の論文『Using Sparse Capabilities in a Distributed Operating System』は形式を明記している。サーバーポート48ビット、オブジェクト番号24ビット、権利フィールド8ビット、チェックフィールド48ビット、合計128ビットである。

ポートとオブジェクト番号を一つの住所とみなすと、境界がぼやける。ポートはAmoebaのRPCモデルでサービスへ到達するための識別子であり、オブジェクト番号はそのサービスの内部で解釈される。1991年の状況報告は、ファイルサーバーにおけるオブジェクト番号をinode番号になぞらえた。カーネルはポートを使ってサーバーを探せるが、capabilityの残りを意味づけるのはサーバーである。

8ビットの権利は、全サービス共通の八つの命令ではない。各サーバーのインターフェースが意味を決めるビットマップだ。ファイルなら読み出し、書き込み、削除かもしれず、プロセスなら開始、停止、状態取得かもしれない。同じ幅であっても、異なるオブジェクト型の操作を同一にはしない。共通しているのは、ベアラーに与える操作面を小さく明示できる点である。

チェックフィールドは、見えるオブジェクト番号と権利を、サーバーが保持するオブジェクト固有の秘密に結びつけた。ユーザープロセスが権利ビットをメモリー上で書き換えること自体はできても、その書き換えに対応する正しいチェック値を作れるとは限らない。サーバーは一方向関数を用いる規則で整合性を検証し、権限の水増しを拒否する。

ただし「偽造不能」は時代と前提を伴う表現である。歴史上の方式は想定した計算能力と秘密管理の下で偽造を困難にしたのであって、48ビットのフィールドを現代の攻撃予算に対して無条件に保証する言葉ではない。正規の所持者からコピーされたトークンの悪用も、平文の通信路で漏れたcapabilityも、チェックそのものでは防げない。1991年報告も、安全でない環境での偶発的な開示を防ぐには暗号が必要になり得ると述べている。

権限縮小は足し算ではなく、単調な引き算だった

所有者用capabilityは、すべての権利ビットを持つ形で始まる。別のプロセスへ限定された権限を渡したい場合、所持者はマスクを指定して制限を依頼できる。サーバーは元のcapabilityを検証し、既存権利とマスクの積集合を取り、同じオブジェクトについて新しいチェック値を持つ制限済みcapabilityを作る。プログラミングガイドのstd_restrictが示す核心は簡潔で、rights &= maskである。

この向きは変えられない。マスクで権利を落とすことはできるが、元のcapabilityが持たない権利を追加することはできない。見える権利ビットだけを増やせばチェック値との対応が崩れ、サーバーは拒否する。したがってattenuationは「委任」という言葉の演出ではなく、検証可能な権限の減算だった。

資料間の方式を一つに混ぜてもいけない。1986年論文は複数の保護案を検討する。保存した乱数と権利を一方向関数で結ぶ案、サーバーに制限済みトークンを発行させる案、可換な一方向関数群でローカルな権限縮小を可能にする案である。1991年報告は、その説明時点のAmoebaで使うサーバー支援方式を記す。これらは同じ研究系譜に属するが、一つの同一アルゴリズムではない。

著者の境界も同様に保つ必要がある。1986年論文はAndrew S. Tanenbaum、Sape J. Mullender、Robbert van Renesseの共著であり、1991年報告はTanenbaum、M. Frans Kaashoek、van Renesse、Henri E. Balの共著である。Tanenbaumはこの歴史をたどる妥当な人物軸だが、Amoebaを一人の発明物へ縮めてはならない。

所持は権限だったが、身元ではなかった

1986年論文は、所持者がビット列を送ることで別のプロセスへ正確なコピーを渡せると説明する。また、誰がどのcapabilityを持つかをシステムが中央で記録しなくてもよい。この二つの性質が可搬性と位置透過性を支える一方、証拠としての限界も決める。

チェック成功から分かるのは、提示されたトークンがサーバーの現在の秘密に照らして対象オブジェクトと権利に適合することだ。オブジェクト作成者から直接受け取ったのか、ディレクトリ経由で取得したのか、別プロセスから再委譲されたのか、漏えい箇所からコピーされたのかは分からない。別の仕組みが結びつけない限り、従業員名、職務、契約上の主体とも対応しない。

目的も同じである。書き込み権限のあるトークンは、通常保守にも、障害復旧にも、承認されていない実験にも使える。権利ビットはサーバーが受け付ける動詞を制約するが、なぜ今その動詞を選んだのかという業務上の根拠は符号化しない。

失効も限定された意味を持つ。サーバーに保存した乱数を変更すれば、対象オブジェクトの既存capabilityをまとめて無効化できる。これは強力なオブジェクト単位のリセットだが、個々のコピーの所在を把握する機能でも、過去の利用者を遡及的に特定する証拠でも、すべてのプロセスや保存媒体から漏れたビット列を消す操作でもない。

サーバーの成功応答は、意味の境界で止まる

有効なcapabilityで許可された操作を実行し、サーバーが成功を返したとする。強く言えるのは、そのサーバー実装が定義する操作を受理し、実行したということまでである。変更がクラッシュ後にも残ったか、すべてのレプリカへ届いたか、物理アクチュエーターが動いたか、外部の送金が完了したか、組織の変更手続きに適合したかは自動的には証明されない。

永続性はストレージと復旧の境界に属する。ネットワークや物理世界の効果は、それを実行し観測する下流システムに属する。人の承認は、委任を定める組織に属する。小さなトークンが一つの操作を開けても、その後に期待されるすべての出来事の万能領収書にはならない。

Amoebaのcapabilityが今も有用なのは、命名と保護を明快に結び、そこで止まるからだ。この停止線は欠点ではない。メカニズムを理解可能にする境界である。

出典