ルールと権限PostgreSQLのルールシステムによる問い合わせの書き換えによって、オリジナルの問い合わせで使われたものではない他のテーブル/ビューがアクセスされます。更新ルールを使うことによってテーブルへの書き込みアクセスを包含することができます。書き換えルールに別々の所有者はいません。リレーション(テーブルまたはビュー)の所有者は自動的にそれに定義された書き換えルールの所有者となります。PostgreSQLのルールシステムはデフォルトのアクセス制御システムの振舞いを変更します。ルールによって使用されるリレーションは、ルールを起動したユーザの権限ではなく、ルール所有者の権限でチェックされます。このことは、ユーザは問い合わせで明記するテーブル/ビューに対しての権限だけあればよいことを示しています。あるユーザが、いくつかは個人用の、その他は事務所で秘書が利用するための、電話番号のリストを持っていたとします。ユーザは次のようにして構築することができます。secretary;そのユーザ(とデータベースのスーパーユーザ)以外はphone_dataテーブルにアクセスできません。GRANTにより秘書はphone_numberビューに対しSELECTできます。ルールシステムはphone_numberからのSELECT操作をphone_dataからのSELECT操作に書き換えます。そのユーザはphone_numberの所有者、したがってルールの所有者ですから、phone_dataの読み込みに対するアクセスはそのユーザの権限に従ってチェックされ、問い合わせを受け付けてもよいことになります。phone_numberへのアクセスもチェックされますが、これは呼び出したユーザに対して行われますので、秘書とユーザ以外は使うことができません。権限はルールごとにチェックされます。秘書だけが今のところ公開の電話番号を参照することができます。秘書は別のビューを作成し、それにPUBLICに対するアクセス許可を与えることができます。すると秘書のビューを通して誰もがphone_numberデータを見ることができます。(実際には作成はできますが、アクセスは全て、権限チェックで拒絶されます)。秘書が独自のphone_numberビューを開いたことにユーザが気付いた時点で、秘書の権限を取り上げることができます。秘書のビューへのアクセスは即座に失敗に終わります。このルールごとのチェックがセキュリティホールになると考える人がいるかもしれませんが、実際にはそうではありません。このように機能しないとなると、秘書はphone_numberと同じ列を持ったテーブルを用意して、1日1回データをそこにコピーするかもしれません。なると、データは彼のものですから、誰にアクセス権を与えようが彼の自由です。GRANTは"あなたを信用しています"ということです。信用している誰かがこのようなことを行った場合は、考えを変えてREVOKEしてください。上に示したような手法を使ってある列の内容を隠すのにビューは使えますが、security_barrierフラグが設定されていない限り、見えない行にあるデータを隠す信頼できる方法ではない事に注意してください。以下のビューは安全ではありません。'412%';ルールシステムがphone_numberからのSELECTをphone_dataからのSELECTに書き換え、phoneが412で始まらない項目のみが必要だという条件を追加しますので、このビューは安全に見えます。LIKE式の前にユーザ定義の関数を実行するようプランナを説得することは難しくありません。LIKEの前に安価なtricky関数を実行することを選びますので、phone_dataテーブルの人と電話番号はすべてNOTICEとして表示されます。ユーザが新しい関数を定義できない場合でも、同様の攻撃で組み込み関数が使えます。(例えば、ほとんどの型変換関数は生成するエラーメッセージを入力値に含んでいます。)同様の考慮は更新ルールにも適用できます。前節の例において、データベースのテーブルの所有者はshoelaceビューに対し、誰かにSELECT、INSERT、UPDATE、DELETE権限を与えることができます。shoelace_logに対してはSELECTだけです。ログ項目を書き込むルールアクションは支障なく実行され、また、他のユーザはログ項目を見ることができます。他のユーザは項目を捏造したり、既に存在する項目を操作する、あるいは削除することはできません。この場合、shoelace_logを参照しているルールは条件のないINSERTだけですので、操作の順序を変えるようにプランナを説得することでルールを破壊する可能性はありません。これはより複雑な状況では正しくないかもしれません。が行レベルセキュリティを提供する場合には、そのビューにはsecurity_barrier属性を付与するべきです。これは、悪意を持って選ばれた関数や演算子が、ビューが適用されるより前に取り出された行に対して実行されないようにします。上記のビューが次のように定義された場合、これは安全です。'412%';security_barrierを付けて定義されたビューは、このオプションなしのビューよりも性能の劣るクエリ実行プランを生成します。一般的に、最も高速だが、セキュリティ上の問題があるクエリ実行プランを破棄しなければならないという状況は不可避です。そのため、このオプションはデフォルトでは有効になっていません。プランナは副作用のない関数をもう少し柔軟に扱います。これらの関数はLEAKPROOF属性を持っており、等価演算子など、単純で広く用いられる演算子も多く含まれます。利用者に対して不可視な行に対するこれら関数の呼び出しはいかなる情報も漏えいさせないため、プランナはこれらの関数をどのような場所でも安全に実行させる事ができます。これがもしセキュリティ・ビューの条件句でフィルタリングされるより前に適用されたなら、不可視行に関する何か重要な情報を与える事ができてしまいます。ビューがsecurity_barrier属性付きで定義されたとしても、それは限定的な意味で安全である、つまり不可視な行の内容が潜在的に安全でない関数に渡される事がないという事を意図しているにすぎません。EXPLAINを用いてクエリ実行プランを見たり、ビューに対するクエリ実行時間を計測したり、利用者は不可視な行に対して何らかの推測を行うかもしれません。悪意の攻撃者は不可視データの量を推測したり、分散や最頻値(なぜなら、これらは統計情報を通じて実行プランの選択、ひいては実行時間に影響するかもしれません)に関する何らかの情報を得る事ができるかもしれません。この種の"隠れチャネル"に対する対策が必要であれば、とにかくデータに対するアクセスを許可するのは得策ではありません。ルールおよびコマンドの。