Re: Strange permission problem regarding pg_settings

[ please respect moving of thread to pg-hackers ]

Joe Conway <mail(at)joeconway(dot)com> writes:
> ISTM that we want the relations in the un-rewritten query checked based
> on the basis of the user referencing the rule and for the modes used in
> the un-rewritten query -- suggesting the change need be reverted.

Reverting the change will bring back the bug for which it was created.
It does seem though that we have an inadequate model of how to perform
permission checks. In particular, the "write" flag bit in RTEs is
context dependent: it can mean insert, update, or delete permission
depending on the surrounding command.

The problem the earlier bug report identified is really that when an RTE
is copied from one query to another, the meaning of its "write" flag bit
changes --- incorrectly --- if the new query is of a different type.
I thought when making that patch that we could make an end-run around
this problem by zeroing out the flag bit, but what we're now realizing
is that that leaves us with no check at all in some scenarios (because
the original query will be dropped completely when INSTEAD is specified).

I begin to think that the only real solution is to change the RTE
representation to identify the exact permission bits to be checked for
each entry (say, replace the read and write booleans with a permission
bitmask). Then a view reference specifying INSERT permission check
could be copied into an UPDATE query without changing its permission
semantics.

This would be a fairly extensive change though. Does anyone see an
easier way?

Also, does anyone see a case where it would be correct for the checked
permission to change when an RTE is copied to a query of a different
type?

regards, tom lane