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: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Turner, Ian" <Ian(dot)Turner(at)deshaw(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 19:53:33
Message-ID: 26166.1262289213@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Turner, IanDate: 2009-12-31 19:57:22
Subject: Re: Re-enabling SET ROLE in security definer functions
Previous:From: Heikki LinnakangasDate: 2009-12-31 19:44:17
Subject: Re: Re-enabling SET ROLE in security definer functions

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