On 08.06.21 21:29, David Christensen wrote:
> So basically where we are dispatching to the CASCADE guts, first
check session user’s DELETE permission and throw the normal
permissions error if they can’t delete?
Actually, you also need appropriate SELECT permissions that correspond
to the WHERE clause of the DELETE statement.
So this would be both a table-level and column level check? (It seems
odd that we could configure a policy whereby we could DELETE an
arbitrary row in the table, but not SELECT which one, but I can see that
there could be information leakage implications here.)
Other permissions-level things to consider, like RLS, or is this part
automatic? Do you happen to know offhand another instance in the code
which takes these granular permissions into consideration? Might help
bootstrap both the understanding and the implementation of this.
All of this permissions checking code already exists in the executor, so
the question perhaps isn't so much which details to consider but how to
make use of that code. If you convince the trigger actions to run as
the invoker of the original DELETE rather than whatever they are doing
now, that should all work correctly. How to do that, I don't know right
now.
