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>
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:34:28
Message-ID: 5D5C2F4B28E2514BBAB8E82572912B641C7E86361A@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]
> Really?  What can it contain, and how are you enforcing that?

Anything except a function call. We look for non-keyword identifier followed by open parenthesis, which is probably excessively restrictive. I'd rather have something less kludgey, of course. This will also become a real nightmare if new identifier quoting approaches are introduced.

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

We don't want to have to check access privileges on every object referenced by the statement, which (as I'm sure you're aware) can get real nasty real quick.

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

Not sure what you mean here, can you elaborate?

--Ian

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-31 20:50:59
Subject: Re: Re-enabling SET ROLE in security definer functions
Previous:From: Tom LaneDate: 2009-12-31 20:27:11
Subject: Re: Re-enabling SET ROLE in security definer functions

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