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
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:
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 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
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.