From: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: sudo-like behavior |
Date: | 2006-04-20 20:43:45 |
Message-ID: | 27606.12.15.136.26.1145565825.squirrel@webmail.webopticon.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, April 20, 2006 4:21 pm, Tom Lane wrote:
> "A.M." <agentm(at)themactionfaction(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-20 21:03:04 | Re: sudo-like behavior |
Previous Message | Karsten Hilbert | 2006-04-20 20:27:20 | Re: sudo-like behavior |