要約

  • RFC 3341はownerとactorに一致する複数エントリから最も具体的なものを選ぶため、個別行の削除で広いワイルドカード許可が再び有効になり得た。
  • 取消しには具体的なall:noneを残す場合があり、行の削除、更新成功、owner通知、有効判定、実際の遮断は別々の証拠だった。

仕様の例では、あるactorの個別エントリがコアデータ送信、プレゼンス購読、監視を許可する。同じownerには、同一ドメインの全actorへコアデータ送信だけを認める広いエントリもある。個別エントリを削除すると、購読と監視は失われるが、データ送信は広い規則から受け継がれる。

削除操作は成功している。対象行も消えている。それでも有効権限はゼロではない。候補集合から最優先の行がなくなり、次の行が選ばれたからだ。RFC 3341は、すべて拒否したいなら個別エントリを消さず、all:noneへ変更するよう示した。空白は拒否ではなく、フォールバックの入口だった。

一行では決まらないアクセス

アクセスエントリはowner、actor、許可するaction、サービスが付けるlastUpdateを持つ。ownerは方針の対象となるエンドポイントまたはサブアドレス、actorはその文脈で権限を受ける主体、actionはサービス名と操作名の組である。core:dataなら、リレー網を通じてownerへデータを送る能力を表す。

actorのローカル部とドメイン部には限定的なワイルドカードを使えた。そのため一つの具体的アドレスが複数行に一致する。選択ではまずownerを限定し、actorが一致する行だけを残す。ドメイン部の具体性が第一キー、ローカル部が第二キーで、完全一致が最良、ワイルドカード同士なら一致範囲の短いものが優先された。

つまり権限は、保存された一行の属性ではなく、候補集合と優先順位と照会した操作から得られる計算結果である。管理画面で行が消えた事実は、データ状態の証拠にはなるが、次の判定がdenyになる証拠にはならない。

各ownerには既定行もあった。owner自身と同一ドメインのAPEXサービスには広い許可、任意ドメインのAPEXサービスにはコアデータ、その他のactorにはall:noneが与えられた。明示行が上書きするのは同じactor値の既定行だけである。監査には保存行だけでなく、既定規則も必要になる。

拒否は「ないこと」では表せなかった

既存エントリを削除するsetでは、owner、actor、現在のlastUpdateを送り、actionsを省略する。アクセスサービスは行を削除し、変更元へ成功replyを返す。同時に、actionsのないsetをownerへ別送し、削除を通知する。

その直後に仕様は、actorのワイルドカードがあるため削除が権限を除去せず変更するだけの場合があると注意する。all:noneは「どの操作も許可しない」という特別なactionである。個別actorの行として残ることで広い行より先に選ばれ、拒否を維持する。

これは保存が必要な否定情報である。行がないことは「個別指定なし」であって「禁止」と同義ではない。一般的な墓石掃除がall:noneを不要データとして消せば、新しいgrantを作らなくても権限が復活する。きれいな表が安全な表とは限らない。

更新版の一致と、適用結果の一致

変更前には通常getで現在行を取得し、返されたlastUpdateを後続のsetに付けた。版付き更新なのに完全一致するactor行がなければ、または値が現在行と意味的に同一でなければ、サービスは555を返す。新規作成はlastUpdateなしで行う。

この比較は、取得後に他者が行を変えた場合の上書きを防ぐ。作成や更新後、サービスは自身の現在時刻を新しい値として設定し、置換前と異なるべきだとされた。

しかし版一致は、そのサービスでの書込み競合を閉じるだけである。ownerが通知を受けたこと、全リレーやキャッシュが新しい候補集合を見たこと、次の操作が拒否されたことまでは証明しない。必要な連鎖は、取得行と版、提出変更、受理または競合、新状態、通知送信、通知受領、判定再計算、実行点の更新、試験操作の結果である。

方針を尋ねる権限

アクセスサービスのwell-known endpointへ到達できても、誰もが方針を読めるわけではない。queryを受けたサービスは、subjectが自管理ドメイン内の有効アドレスか確認し、subjectの方針から「query送信者」に一致する行を選び、access:queryを要求する。その後初めて「調べられるactor」に一致する行を選び、列挙された全actionが含まれるか判定する。

尋ねる者と調べられる者は別の主体である。問い合わせ権は実行権ではない。allowも、その時点で選ばれた行に全actionが含まれたという返答であり、後のデータ操作が同じ版を見たことや成功したことではない。

実装はアクセスエントリを永続ストレージへ保存し、ownerがリレー網へ現在接続しているかにかかわらず維持する必要があった。切断は取消しではない。永続化は方針を在席状態より長生きさせるが、複製の収束、新鮮さ、全実行点での適用を保証する言葉ではない。

Historicになっても残る区別

RFC 3341は2002年7月にStandards Trackで発行され、APEXのcore、access、options、presenceを構成する四文書の一つだった。IETF Datatrackerは2012年7月29日、四文書をHistoricへ変更した理由を記録している。IETFが知る限り実装は配備されず、機能はRFC 6120とRFC 6121の広く配備されたXMPPが提供していた。

この記録は採用結果を限定付きで述べるが、アクセス規則が原因だったとは述べない。脆弱性や事故の証拠でもない。それでも仕様が示した境界は明快である。行を消すこと、有効権限を取り消すこと、実行点で拒否することは同じ出来事ではない。

現代の方針系へ適用する際も、APEXと同じ実装だとは主張せず、この証拠の分け方だけを使えばよい。編集対象行ではなく全候補と判定アルゴリズムを保存し、優先順位に必要な明示denyは別の保持方針で守る。変更後は有効判定を読み、実行点で試す。変更成功はサービスが何を受けたかを示す。取消し完了は、主体が何をできなくなったかで閉じる。

出典