要約

  • Jerry Saltzerが1974年に示した比較では、CTSSの共有リンクは利用方法にも関わったため、借り手側のディレクトリを直さなければ失効できず、権限の全体像を調べるにも全ディレクトリの探索が必要だった。
  • Multicsはリンクを間接アドレスとして残し、権限判断を参照先セグメントのアクセス制御リストに置いた。ただし、コピー済み情報や古い判断を保持するセッションまで自動的に取り戻す仕組みではない。

ある利用者が同じファイルを二つのリンクから開く。一方では読めて、もう一方では書ける。柔軟に見えるが、管理者が「この人の権限を取り消す」と決めた瞬間、どの場所を変更すればよいのかが曖昧になる。入口が利用者のディレクトリに散らばっていれば、資源の所有者だけでは撤回を完結できない。

SaltzerはCTSSの共有方式に、この問題を見た。CTSSでは、他人の元ファイルを指す特別なリンクを自分のディレクトリに置き、リンクに利用モードの追加制限を持たせることができた。ところが、リンクができた後にアクセスを取り消すには借り手のディレクトリを変更しなければならない。同一人物の権限が使用した名前によって変わり、監査では全利用者のディレクトリからリンクを探す必要があった。

Multicsは別名を禁止したのではない。リンクの仕事を限定した。リンクは資源を見つけるための間接アドレスであり、それ自体にはアクセス特権がない。許可は参照先に結び付いたアクセス制御リストで決まる。

経路ではなく参照先で決める

Saltzerの論文では、Multicsの記憶域は名前を持つセグメントで構成される。セグメントは登録単位であると同時に、プロセスの仮想記憶へ写像される単位であり、個別に保護される単位でもあった。プロセスには偽造できない主体識別子があり、登録された資源へアクセスしようとすると、その識別子と資源のリストが比較される。

何をするかも判断の一部だった。セグメントでは読み、書き、実行が区別され、メッセージキューやディレクトリには別の操作がある。リンクが答えるのは「どの資源か」であり、リストが答えるのは「どの主体が、どの操作を行えるか」である。

この分離により、別名を増やしても許可の所在は増えない。資源の管理者がリストを変更すれば、個々のリンクを回収しなくても現在の判断を変えられる。監査も、すべての名前空間を横断して隠れた許可を探すのではなく、資源側の規則から始められる。

もちろん、リストには優先順位がある。個人、プロジェクト、区画を組み合わせた主体識別子があり、具体的な項目は一般的な項目より先に適用された。ディレクトリを変更する権限は、その下のアクセス指定を管理する力にもつながった。権限関係は消えず、説明すべき場所が定まったのである。

便利な継承をやめた理由

論文は、Multics自身が一度採用して放棄した方式も記録している。以前は、ディレクトリの初期リストを、その中の各資源に共通する付属リストとして扱っていた。一か所の変更を広く効かせられる反面、各資源の既存項目との組合せで結果が変わり、利用者が影響を予測しにくかった。

そこで、新しい資源を作る時点で初期リストをコピーする方式に変えた。後からディレクトリの初期値を直しても既存資源には波及しない。動的な柔軟性は失われたが、各資源の現在の状態は読み取りやすくなった。Saltzerはアクセス制御を、表現力、理解しやすさ、実装コストの三者の妥協として扱っている。

リンクの権限を外した判断も同じ方向を向く。経路ごとに細かな条件を付けられるほど例外は増える。例外が分散すれば、退職、プロジェクト移動、緊急遮断のときに、何を閉じればよいか分からなくなる。制約を減らすことが、管理可能性を増やす場合がある。

保存された判断に変更を届ける

SaltzerとMichael D. Schroederが1975年の論文で整理した原則の一つが、完全な仲介である。資源へのアクセスは権限に照らして確認されなければならない。Saltzerの1974年の記述は、稼働を続けるシステムが判断を将来利用のために記憶する場合、権限変更をその局所記憶へどう伝えるかを考える必要があると付け加える。

これは、一度中央リストを更新すれば終わり、という話ではない。ファイルを開いた時点やセグメントを写像した時点で確認しても、開いたハンドル、写像、セッション、キャッシュが古い結果を保持する可能性がある。すべてのバイト操作でリストを読み直すと論文が主張しているわけでもない。

運用記録には、主体、最終的に解決された資源、要求操作、参照した規則の版、判断時刻、そこから生じた状態の有効期間が必要になる。失効側には、変更の受付だけでなく、どのセッションやキャッシュを無効にし、その後のどの試行が拒否されたかという別の証拠が要る。

読み出された情報は戻らない

失効を明快にしても、開示は逆転しない。Saltzerは、読む許可を持つ利用者がコピーを作れることを明記している。元セグメントの権限を取り消しても、そのコピーは消えない。許可後の情報流通をどう縛るかは未解決の領域だった。

Multicsも完成品として美化されていない。論文は未実装の部分や、最も強く保護された領域に多くのモジュールが残るという弱点を挙げる。名前と権限の境界は、信頼対象を見えるようにする。信頼対象が正しいことまで証明するものではない。

現代の共有URL、エイリアス、資源ハンドルにも同じ混同が起こる。名前が存在すること、許可が有効なこと、実際に使われたこと、失効が末端まで届いたことは別々の事実である。リンクは残ってもよい。開けるかどうかは、リンクの外で改めて決められなければならない。

出典