Re: Re-enabling SET ROLE in security definer functions - Mailing list pgsql-hackers

From Turner, Ian
Subject Re: Re-enabling SET ROLE in security definer functions
Date
Msg-id 5D5C2F4B28E2514BBAB8E82572912B641C7E863615@NYCMBX3.winmail.deshaw.com
Whole thread Raw
In response to Re: Re-enabling SET ROLE in security definer functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re-enabling SET ROLE in security definer functions  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.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
privilegesfor a particular operation. Our particular use case is that we want to evaluate an expression provided by the
callerbut with the caller's privileges. 

Cheers,

--Ian


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: uintptr_t for Datum
Next
From: Robert Haas
Date:
Subject: Re: Status of plperl inter-sp calling