ルールとパーミッション

Due to rewriting of queries by the Postgres rule system, other tables/views than those used in the original query get accessed. Using update rules, this can include write access to tables.

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

Rewrite rules don't have a separate owner. The owner of a relation (table or view) is automatically the owner of the rewrite rules that are defined for it. The Postgres rule system changes the behaviour of the default access control system. Relations that are used due to rules get checked during the rewrite against the permissions of the relation owner, the rule is defined on. This means, that a user does only need the required permissions for the tables/views he names in his queries.

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

For example: A user has a list of phone numbers where some of them are private, the others are of interest for the secretary of the office. He can construct the following:

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

    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;

Nobody except him (and the database superusers) can access the phone_data table. But due to the GRANT, the secretary can SELECT from the phone_number view. The rule system will rewrite the SELECT from phone_number into a SELECT from phone_data and add the qualification that only entries where private is false are wanted. Since the user is the owner of phone_number, the read access to phone_data is now checked against his permissions and the query is considered granted. The check for accessing phone_number is still performed, so nobody than the secretary can use it. そのユーザ(とデータベースのスーパユーザ)以外は phone_data テーブル にアクセスできません。しかし、GRANT により秘書は phone_number ビュー に対し SELECT from できます。ルールシステムは SELECT from phone_number を SELECT from phone_data に書き換え、private が偽となっている項目 のみを使用するという条件を付け加えます。 そのユーザは phone_number の所有者ですから、 phone_data の読み込みに対するアクセスはそのユーザのパーミッション にしたがってチェックされ、問合せを受け付けてもいいことになります。 phone_number へのアクセスはチェックされ続けられますので、秘書以外 は使うことが出来ません。

The permissions are checked rule by rule. So the secretary is for now the only one who can see the public phone numbers. But the secretary can setup another view and grant access to that to public. Then, anyone can see the phone_number data through the secretaries view. What the secretary cannot do is to create a view that directly accesses phone_data (actually he can, but it will not work since every access aborts the transaction during the permission checks). And as soon as the user will notice, that the secretary opened his phone_number view, he can REVOKE his access. Immediately any access to the secretaries view will fail.

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

Someone might think that this rule by rule checking is a security hole, but in fact it isn't. If this would not work, the secretary could setup a table with the same columns as phone_number and copy the data to there once per day. Then it's his own data and he can grant access to everyone he wants. A GRANT means "I trust you". If someone you trust does the thing above, it's time to think it over and then REVOKE.

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

This mechanism does also work for update rules. In the examples of the previous section, the owner of the tables in Al's database could GRANT SELECT, INSERT, UPDATE and DELETE on the shoelace view to al. But only SELECT on shoelace_log. The rule action to write log entries will still be executed successfull. And Al could see the log entries. But he cannot create fake entries, nor could he manipulate or remove existing ones.

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