From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Turner, Ian" <Ian(dot)Turner(at)deshaw(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, George Williams <george(dot)williams(at)enterprisedb(dot)com> |
Subject: | Re: Re-enabling SET ROLE in security definer functions |
Date: | 2009-12-31 20:27:11 |
Message-ID: | 29540.1262291231@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Turner, Ian | 2009-12-31 20:34:28 | Re: Re-enabling SET ROLE in security definer functions |
Previous Message | Tom Lane | 2009-12-31 20:18:30 | Re: Thoughts on statistics for continuously advancing columns |