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.