"Turner, Ian" <Ian.Turner@deshaw.com> writes:
>> 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 excessively
> restrictive.
I'm afraid this is security by wishful thinking. Operators and casts,
to name two obvious examples, can invoke user-defined code. Postgres
is sufficiently extensible that preventing any execution of non-core
code is nearly impossible, at least not without limiting things to
the point of uselessness.
>> 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?
>> 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?
If you had a mechanism that ensured that the untrusted user couldn't
execute SET ROLE (which you don't), they couldn't execute anything else
either, and therefore the question of what permissions they're running
with isn't really important.
I agree that you have a problem to solve, but defining the problem as
"please can we have SET ROLE back" is not going to lead you to a secure
solution.
regards, tom lane