On Sun, Jan 27, 2013 at 1:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jan 25, 2013 at 2:59 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >>> 2013/1/20 Tom Lane <t...@sss.pgh.pa.us>: >>>> The traditional answer to that, which not only can be done already in >>>> all existing releases but is infinitely more flexible than any >>>> hard-wired scheme we could implement, is that you create superuser-owned >>>> security-definer functions that can execute any specific operation you >>>> want to allow, and then GRANT EXECUTE on those functions to just the >>>> people who should have it. > >> This is valid, but I think that the people who want this functionality >> are less interest in avoiding bugs in trusted procedures than they are >> in avoiding the necessity for the user to have to learn the local >> admin-installed collection of trusted procedures. > > Sure, but given that we are working on event triggers, surely the > correct solution is to make sure that user-provided event triggers can > cover permissions-checking requirements, rather than to invent a whole > new infrastructure that's guaranteed to never really satisfy anybody.
I am not sure whether it's really true that a capability mechanism could "never really satisfy" anyone. It worked for Linux. But, I think event triggers are a credible answer, too, and they certainly are more flexible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
