ルールとパーミッション

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

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

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

    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 from できます。ルールシステムは SELECT from phone_number を SELECT from phone_data に書き換え、private が偽となっている項目 のみを使用するという条件を付け加えます。 そのユーザは phone_number の所有者ですから、 phone_data の読み込みに対するアクセスはそのユーザのパーミッション にしたがってチェックされ、問合せを受け付けてもいいことになります。 phone_number へのアクセスはチェックされ続けられますので、秘書以外 は使うことが出来ません。

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

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

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