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

Re: Re-enabling SET ROLE in security definer functions

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Turner, IanDate: 2009-12-31 20:34:28
Subject: Re: Re-enabling SET ROLE in security definer functions
Previous:From: Tom LaneDate: 2009-12-31 20:18:30
Subject: Re: Thoughts on statistics for continuously advancing columns

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