Re: Re-enabling SET ROLE in security definer functions

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Turner, Ian wrote:
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>>> Actually, I don't find that to be a given. Exactly what use-cases have
>>> you got that aren't solved as well or better by calling a SECURITY DEFINER
>>> function owned by the target role?
>>
>> Oh, that's easy: If you want to do the equivalent of setreuid(geteuid(), getuid()); that is, if you want to drop privileges for a particular operation. Our particular use case is that we want to evaluate an expression provided by the caller but with the caller's privileges.

> Now *that's* what we should focus on. That's a reasonable use case, but
> it doesn't seem like SET ROLE quite cuts it.

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.

regards, tom lane