要約

  • IMAPのACLは識別子と権利の組から成る。一人の利用者が個人名、複数のグループ、anyone に同時に該当するため、一行は認可計算への入力にすぎない。
  • GETACL は登録規則、LISTRIGHTS はその識別子に付与可能な権利、MYRIGHTS は現在のセッションに対する実効結果を返す。
  • DELETEACL は一組を削除する。negative right は計算時に権利を差し引く。RFC 4314は両者を区別したが、識別子の結合方法まで中央で統一しなかった。

「削除しました」の外側

権限画面は、複雑な認可を表に変える。名前を選び、行を消し、保存完了を受け取る。その操作が本当の失効になるには、消した行が唯一の経路であり、実行サーバーが新しい状態を評価し、既存セッションも古い判断を使っていないことが必要だ。

共有メールボックスは、この条件を早くから崩した。サポート用の箱はチームで扱われる。個人への直接付与、グループ経由の付与、全体向けの付与が重なる。一覧は「なぜ許され得るか」を並べるが、「最終的に何が許されるか」とは限らない。

RFC 1730 は、遠隔メールボックスをネットワーク越しに操作できる対象として記述した。クライアントは箱を選択し、メッセージを読み、フラグを変え、サーバー上の状態を動かす。複数の人が同じ対象を扱うなら、サーバー内部だけにあるファイル権限では、遠隔クライアントが自分の可能な操作を知れない。

1997年1月のStandards Track文書 RFC 2086 は、ACL capabilityを加えた。メールボックスのACLは、識別子と権利文字列の組の集合である。クライアントはサーバーのアカウント台帳全体を受け取らずに、その組を照会し変更できた。

一つの接続に一つとは限らない名前

規格は anyone を、匿名を含む普遍的な識別子として予約した。LOGIN や AUTHENTICATE が受理する利用者名は対応する利用者を表す。それ以外の識別子は、グループなど実装固有の意味を持ち得た。

したがってFredの接続は、fred、support-team、anyone の全てに一致し得る。複数の一致をどう合わせるかは、RFCが一種類に決めなかった。全ての権利を和集合にするサーバーも、最も具体的な識別子だけを選ぶサーバーもあり得る。

これはクライアントに与えられた推測権ではない。画面に行が見えても、実際のグループ所属、所有者に強制される権利、優先順位は見えないことがある。同じような表から、適合する二つのサーバーが別の答えを出せる。

そこで MYRIGHTS が必要になった。接続中の利用者について、対象メールボックスの実効権利を実行サーバー自身に尋ねる。次のコマンドを受理する当事者が、現在の計算結果を返すのである。

三つの問いを一つに潰さない

GETACL は保存された識別子と権利の組を返す。宣言済みの規則は何か、という問いである。どの規則が現在の利用者に当たり、どう結合されるかまでは答えない。

LISTRIGHTS は、ある識別子に何を付与できるかを示す。基盤が複数の権利を切り離せない場合、必須部分や一括でしか選べない部分を応答に表す。これはサーバーが表現できる変更の範囲であり、現在の許可ではない。

MYRIGHTS は識別子解決とローカルな結合後の集合である。実効状態を問うが、なぜその集合になったかを全て説明するものでも、資格情報を操作する人間を証明するものでもない。

ACLの再読込、実効権利の照会、保護された操作の成功は別々の証拠である。規則の保存が成功しても実効結果が同じことはあり、実効結果が変わっても別セッションが古い値を持つことはある。

行の削除と権利の差し引き

DELETEACL mailbox fred は fred の組を除く。グループや anyone が w を与えていれば、コマンドは完全に成功しながらFredの書込み権を残す。

RFC 2086は、ハイフンで始まる識別子をnegative rights用に予約した。RFC 4314 は違いを明示した。-fred に w を置けば、他の一致した識別子から得る場合でもFredの w を計算から差し引く。negative entryは評価式に残る。DELETEACL は一つの正または負の組を消すだけである。

ただし、negative rightsの実装は必須ではない。クライアントは規格に表記があるという理由だけで、全サーバーに通用する「拒否優先」を約束できない。対応を確認し、MYRIGHTS と実操作で結果を検証する必要がある。

ハイフンの場所にも意味がある。SETACL の権利引数にある -w は、その一組から w を除く。識別子位置の -fred は、計算に参加する負の識別子である。前者は行の編集、後者は継承を打ち消し得る入力であり、同じ記号でも作用範囲が違う。

古いクライアントを残しながら権限を細分化する

最初の拡張は、可視性、読取り、既読状態、その他のフラグ、挿入、投稿、作成、削除、管理を一文字ずつにした。しかし c と d は広すぎた。メッセージに削除印を付けること、実際に消去すること、メールボックスそのものを消すことが混線した。

2005年12月にRFC 2086を置き換えたRFC 4314は、子メールボックス作成を k、メールボックス削除や移動を x、メッセージの削除印を t、消去を e に分けた。旧来の c と d は互換用の仮想権利として返せた。新サーバーは細かく実行し、旧クライアントには定義済みの粗い投影を見せられた。

RIGHTS= capabilityは追加権利を通知した。基盤上どうしても一緒に動く権利は、LISTRIGHTS で結合を示した。共通規格は、ローカルの保存機構が全て同じ粒度だとは装わなかった。

さらに、読書き可能なACLクライアントは、編集できない未知の権利を保存しなければならない。古い画面が知っている文字だけを書き戻せば、新しい権利を無言で削除するからだ。拡張可能性とは、未知をゼロとして扱わない規律でもあった。

失効には時間の境界もある

RFC 4314は、メールボックス選択時にサーバーが権利をキャッシュすることを認めた。SETACL や DELETEACL の後も、既に選択したセッションの STORE や EXPUNGE は、再選択まで古い判断を使う場合がある。

毎回確認するサーバーなら、フラグ情報を更新し、操作を拒み、読取り権が消えれば接続を閉じられる。しかし、全セッションに同時に訪れる一つの失効時刻を規格は約束しない。検証すべき境界を示したのである。

同一接続の順序は明確にできた。SETACL と MYRIGHTS を連続送信しても、サーバーは変更を終えてから後者を計算しなければならない。それでも別接続のキャッシュまでは語れない。

規則一覧そのものが秘密になり得る

ACLには本文がなくても、メールボックスの存在、利用者、グループ、管理者を明かす。RFC 2086は権限のない GETACL が保護された箱を漏らさないよう求めた。RFC 4314では、一覧権のない利用者への応答を、箱が存在しない場合と同じにする。

メッセージの読取り権だけでACLを見せることも避けた。識別子の並びがセキュリティ情報だからである。そしてACL拡張自体は暗号化ではない。STARTTLS、認証時のプライバシー保護、その他の機構がなければ、一覧は平文で流れる。

認可の正しさと、その認可情報を運ぶ通信の秘密性は別の責任だった。

統一しない部分を明記した規格

RFC 4314は既知の不足も列挙した。識別子の結合規則は実装依存で、利用者、グループ、特別な識別子が同じ名前空間に入り、一般的なUIを作りにくい。ファイルシステムの所有者変更に相当する操作も十分ではなかった。

それでもRFC 2086が複数実装に展開済みだったため、後方互換の改善には価値があるとした。RFC 9051 が後にIMAP4rev2を定義し、特記がない登録済みIMAP4rev1拡張を概ね引き継いだ。これは規格の連続性であり、現在の全サービスがACLやnegative rightsを持つという調査結果ではない。

歴史的な成果は小さい共通層にある。IMAPは一枚の一覧を主権者にしなかった。宣言された規則、サーバーが表現できる変更、実行コードが計算した権限を、遠隔から区別できるようにした。

出典