| From: | "Turner, Ian" <Ian(dot)Turner(at)deshaw(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | 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 19:57:22 |
| Message-ID: | 5D5C2F4B28E2514BBAB8E82572912B641C7E863618@NYCMBX3.winmail.deshaw.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> -----Original Message-----
> 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. But there are alternative: We could create an in-transaction SECURITY DEFINER procedure which executes the expression, then drop the procedure before committing. A built-in feature for doing something like what Heikki suggests could be even more useful.
Cheers,
--Ian
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-12-31 20:17:29 | Re: Serializable Isolation without blocking |
| Previous Message | Tom Lane | 2009-12-31 19:53:33 | Re: Re-enabling SET ROLE in security definer functions |