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>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
Cc: 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 18:09:40
Message-ID: 5D5C2F4B28E2514BBAB8E82572912B641C7E863615@NYCMBX3.winmail.deshaw.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----Original Message-----
> 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.

Cheers,

--Ian

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-12-31 18:14:39
Subject: Re: Status of plperl inter-sp calling
Previous:From: Tom LaneDate: 2009-12-31 18:08:49
Subject: Re: uintptr_t for Datum

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