From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: sudo-like behavior |
Date: | 2006-04-20 21:03:04 |
Message-ID: | 29800.1145566984@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"A.M." <agentm(at)themactionfaction(dot)com> writes:
> On Thu, April 20, 2006 4:21 pm, Tom Lane wrote:
>> 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.
Well, the simplest thing would be
create function exec(text) returns void as $$
begin
execute $1;
end$$ language plpgsql strict security definer;
revoke execute on exec(text) from public;
grant execute on exec(text) to whoever-you-trust;
although personally I'd try to restrict what the function can be used
for a bit more than that. If the allowed commands are in a table, you
could perhaps pass the table's key to exec() and let it pull the string
from the table for itself.
> What about commands that can't be run from within transactions?
There aren't that many of those. Do you really need this for them?
For that matter, do you really need this at all? Have you considered
granting role membership as an alternative solution path? The SQL
permissions mechanism is quite powerful as of 8.1, and if it won't
do what you want, maybe you have not thought hard enough.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomi NA | 2006-04-20 22:20:22 | full text search: the concept of a "word" |
Previous Message | A.M. | 2006-04-20 20:43:45 | Re: sudo-like behavior |