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

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 PostgreSQL rule system changes the behavior
of the default access control system. Relations that are used due
to rules get checked against the permissions of the rule owner,
not the user invoking the rule. This means, that a user does only
need the required permissions for the tables/views he names in
his queries.

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:

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 also performed, but this is done against the
invoking user, so nobody but the user and the secretary can use
it.

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.

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.

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 successfully.
And Al could see the log entries. But he cannot create fake
entries, nor could he manipulate or remove existing ones.

Warning: GRANT ALL currently includes RULE
permission. This means the granted user could drop the rule,
do the changes and reinstall it. I think this should get
changed quickly.