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
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]
> 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

Browse pgsql-hackers by date

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