I'm thinking about changing the way that access permission checks are
handled for rules. The rule mechanism provides that accesses to tables
that are mentioned within rules are done with the permissions of the
rule owner, not the invoking user. The way this is implemented is that
when a rule is substituted into a query, the rule rewriter (a) does its own permission checking on the newly-added
rangetable entries, and (b) sets a "skipAcl" flag in each such RTE to prevent the executor from doing normal
permissionschecking on that RTE.
This is pretty ugly. For one thing, it means near-duplicate code that
has to be kept in sync between the executor and the rewriter. For
another, it's not good that rule-related permissions checks happen at
rewrite time instead of execution time. That means that a cached
execution plan will not respond to later changes in table permissions,
if the access comes via a rule rather than a direct reference.
What I'm thinking about doing is eliminating the "skipAcl" RTE field
and instead adding an Oid field named something like "checkAclAs".
The semantics of this field would be "if zero, check access permissions
for this table using the current effective userID; but if not zero,
check access permissions as if you are this userID". Then the rule
rewriter would do no access permission checks of its own, but would
set this field appropriately in RTEs that it adds to queries. All the
actual permissions checking would happen in one place in the executor.
Comments? Is this a general enough mechanism, and does it fit well
with the various setUID tricks that people are thinking about?
regards, tom lane