On Thu, April 20, 2006 4:21 pm, Tom Lane wrote:
> "A.M." <agentm@themactionfaction.com> writes:
>
>> It seems I am stuck so please allow me to propose an extension:
>> SET SESSION AUTHORIZATION user [WITH PASSWORD 'password];
>>
>
> This idea is extremely unlikely to be accepted, as the password would be
> at risk of exposure in places like the pg_stat_activity view.
>
> I think the correct way to do what you want is via a SECURITY DEFINER
> function.
Perhaps I can't wrap my head around it- I have the SQL as a string in a
table. I interpret that you propose that I accept only function names and
allow users to create security definer functions which I then call as the
superuser (carefully checking for the security definer flag). What about
commands that can't be run from within transactions?
I guess there is no way to stream arbitrary SQL in a permissions sandbox
if the original login user isn't the one I want. The security definer
method is a good enough workaround. Thanks.
-M