Skip site navigation (1) Skip section navigation (2)

Re: Re-enabling SET ROLE in security definer functions

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: (view raw, whole thread or download thread mbox)
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.



In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2009-12-31 20:17:29
Subject: Re: Serializable Isolation without blocking
Previous:From: Tom LaneDate: 2009-12-31 19:53:33
Subject: Re: Re-enabling SET ROLE in security definer functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group