Re: Re-enabling SET ROLE in security definer functions

"Turner, Ian" <Ian(dot)Turner(at)deshaw(dot)com> writes:
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>> Exactly. If that's what you want, we can talk about it, but *SET ROLE
>> doesn't solve that problem*. In fact, a security definer function is a
>> lot closer to solving that problem than SET ROLE is. The premise of SET
>> ROLE is that you can always get to any role that the session user could
>> get to, so it doesn't "give up permissions" in any non-subvertible
>> fashion.

> For our purposes, SET ROLE is adequate, because the expression can't
> contain function calls.

Really? What can it contain, and how are you enforcing that? Even more
to the point, if you have managed to restrict it to the point where
there's no possibility of someone executing a SET ROLE, why do you need
any permissions switch at all? That's isomorphic to claiming that it
won't execute any SQL command at all, in which case you needn't worry about
changing permissions.

regards, tom lane