2009/12/11 KaiGai Kohei <kai...@ak.jp.nec.com>: > It tried to provide a set of comprehensive entry points to replace existing > PG checks at once. > However, the SE-PgSQL/Lite patch covers accesses on only database, schema, > tables and columns. Is it necessary to be comprehensive from the beginning? > It might be too aggressive changes at once. > > Frankly, I hesitate to salvage the patch once rejected, as is. > > If we implement a set of security hooks, It seems to me the following approach > is reasonable: > > * It does not touch the existing PG default checks. > The purpose of security hooks are to host "enhanced" security features. > > * It does not deploy hooks on which no security provider is now proposed. > It is important to reduce unnecessary changeset.
I think that we should try to move the PG default checks inside the hook functions. If we can't do that cleanly, it's a good sign that the hook functions are not correctly placed to enforce arbitrary security policy. Furthermore, it defeats what I think would be a good side goal here, which is to better modularize the existing code. What I would suggest is that you develop a version of that patch that is stripped down to apply to only a single object type (databases? tables and columns - these might have to be together??) and which addresses Tom's criticisms from the last time around, and post that (on a new thread) for discussion. That will be much easier to review (and I will personally commit to reviewing it) but should allow us to flush out some of the design issues. If we can get agreement on that as a concept patch, we can move on to talking about which object types should be included in a committable version of that patch. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
