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 5D5C2F4B28E2514BBAB8E82572912B641C7E86361A@NYCMBX3.winmail.deshaw.com
Whole thread
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
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.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
excessivelyrestrictive. I'd rather have something less kludgey, of course. This will also become a real nightmare if
newidentifier 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re-enabling SET ROLE in security definer functions
Next
From: Tom Lane
Date:
Subject: Re: Re-enabling SET ROLE in security definer functions