On Sun, Jan 27, 2013 at 1:09 PM, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: >> On Fri, Jan 25, 2013 at 2:59 PM, Kohei KaiGai <[email protected]> wrote: >>> 2013/1/20 Tom Lane <[email protected]>: >>>> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
