16.5. ルールと権限

PostgreSQLのルールシステムによる問い合わせの書き換えによって、オリジナルの問い合わせで使われたものではない他のテーブル/ビューがアクセスされます。更新ルールを使うことによってテーブルへの書き込みアクセスを包含することができます。

書き換えルールに別々の所有者はいません。リレーション（テーブルまたはビュー）の所有者は自動的にそれを定義した書き換えルールの所有者となります。PostgreSQLのルールシステムはデフォルトのアクセス制御システムの振る舞いを変更します。ルールによって使用されるリレーションはルール所有者の権限でチェックされます。ルールを起動したユーザの権限ではありません。このことは、ユーザは問い合わせで記述するテーブル/ビューに対しての権限だけあればよいことを示しています。

たとえば、あるユーザがいくつかは個人的な、その他は事務所で秘書が利用する電話番号のリストを持っていたとします。そのユーザは次のようにして構築することができます。

CREATE TABLE phone_data (person text, phone text, private bool);
CREATE VIEW phone_number AS
    SELECT person, phone FROM phone_data WHERE NOT private;
GRANT SELECT ON phone_number TO secretary;

そのユーザ（とデータベースのスーパーユーザ）以外はphone_dataテーブルにアクセスできません。しかし、GRANTにより秘書はphone_numberビューに対しSELECT できます。ルールシステムはSELECT from phone_numberをSELECT from phone_dataに書き換え、privateが偽となっている項目のみを使用するという条件を付け加えます。そのユーザはphone_numberの所有者ですから、phone_dataの読み込みに対するアクセスはそのユーザの権限にしたがってチェックされ、問い合わせを受け付けてもよいことになります。phone_numberへのアクセスはチェックされ続けられますが、これは呼び出したユーザに対して行われますので、秘書とユーザ以外は使うことができません。

権限はルールごとにチェックされます。ですから秘書だけが今のところ一般の電話番号を参照することができます。しかし、秘書が別のビューを作成し、それを一般にたいしアクセス許可を与えれば、秘書のビューを通して誰もがphone_number データを見ることができます。秘書ができないことはphone_dataに直接アクセスするビューを作ることです（実際にはできますが、それぞれのアクセスについての権限チェックでトランザクションがアボートします）。そしてユーザが独自の phone_numberビューを開いたことに気づいた時点で、秘書の権限をREVOKEできます。秘書のビューへのアクセスは即座に失敗に終わります。

このルールごとのチェックがセキュリティホールになると考える人がいるかも知れませんが、実際にはそうではありません。もし機能しないと秘書は1日1 回phone_numberと同じ列を持ったテーブルを用意して、データをそこにコピーしなければなりません。データはそのユーザのものですから、誰にアクセス権をを与えようが彼の自由です。GRANTは"あなたを信用しています"ということです。信用している誰かがこのようなことを行った場合は、考えを変えてREVOKEすることです。

この機構は更新ルールにも適用できます。前節の例において、アルのデータベースのテーブルの所有者はshoelaceビューにたいし、アルにGRANT SELECT、INSERT、UPDATE、DELETEができました。しかし、shoelace_logに対してはSELECT だけです。ログ項目を書き込むルールアクションは支障なく実行されているでしょう。アルはログ項目を見ることができますが、項目を捏造したり、すでに存在する項目を操作したりあるいは削除することはできません。