Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
The next step after that might well be INSTEAD OF event triggers,
allowing users to reimplement some DDL in terms of themselves in PL
code, with the ALTER EVENT TRIGGER … DISABLE; trick to avoid recursion.
> I'm really entirely un-thrilled with a proposal to clutter the privilege
> system like this. Admittedly, it might be a hair more secure than
> user-written plpgsql functions, which could perhaps be subverted if the
> author is careless. But there are a hundred other places where we could
> more usefully spend our implementation and future-maintenance efforts
> than here.
My understanding is that the security minds are shifting towards
capabilities as the way to reduce maintenance efforts and security bug
fixes in the long run:
http://www.erights.org/
Again, as I'm not into security that much, so I will refrain from
commenting any further.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
