データベースで強制
Fóirで行を読み取れる人、変更できる人は、Postgresが決めます。ルールは1つのスペックに一度だけ書かれ、行レベルセキュリティポリシーにコンパイルされるため、チェックはアプリケーションコードの下層で、データとともにあります。
1つの仕様をコンパイルする
アクセスモデルは、1つの仕様ファイルに記述されています。Demesneは私たちのオープンソースのコンパイラで、この仕様からポリシーと、ポリシーが呼び出すデータベース関数を生成します。生成されたSQLはコンパイラが出力したまま出荷され、手作業で編集されることはありません。執筆時点で、約100のテーブルを管理しています。
強制され、実際のスキーマに対して検証される
行レベルセキュリティは、管理対象のすべてのテーブルで有効化されているだけでなく強制されており、テーブルの所有者がポリシーを越えて読み取れる経路を塞いでいます。テストがデータベースのカタログから両方の設定を読み取り、どちらかがオフであれば失敗します。
別のテストがスキーマ内のすべてのテーブルを列挙し、保護方法の決定が記録されないまま追加されたテーブルがあれば失敗します。
リクエストが到達できる範囲
APIへのリクエストは、呼び出し元のワークスペース、プロジェクト、組織をデータベースが読み取るクレームとして持ち込み、これらのポリシーの下で処理されます。各テーブルのポリシーは、他のどのルールよりも先に、それらを行と照合します。呼び出し元が見ることのできない行は、存在しないものとして扱われます。
アプリケーションが判断する部分
データベースには区別できない操作があります。Postgresから見ると、レコードの公開は更新です。そうした権限は、同じ仕様から生成されたマップに照らして、リクエストの到着時に確認されます。そのうえで、行のルールが、その操作が触れられる範囲を引き続き制限します。
仕組みを読む
ドキュメントでは、所有権、可視性、グラント、そして認証情報の種類ごとにリクエストがどのように解決されるかを説明しています。