Hi all I'd like to outline a path toward getting row-security into core. Comments / discussion appreciated.
I think I/we need to: - Finish and commit updatable security barrier views. I've still got a lot of straightening out to do there. - Add an attribute to portals that stores the user ID at the time the portal was planned. Possibly extensibly; I'd be surprised if we won't need to associate other local info with a portal later. - Allow storage of the pre-rewrite query plan and let saved plans be marked as needing rewrite when replanned. We'll need this to permit some users (initially just a hardcoded "superuser"; later by posession of a certain right) to be totally exempt from row-security policy. (Alternative: store separate with- and without-row-security plan trees and pick which we use). - Decide on and implement a structure for row-security functionality its self. I'm persuaded by Robert's comments here, that whatever we expose must be significantly more usable than a DIY on top of views (with the fix for updatable security barrier views to make that possible). I outlined the skeleton of a possible design in my earlier post, with the heirachical and non-heirachical access labels. Should be implemented using the same API we expose for extensions (like SEPostgresql RLS). - Produce and commit a patch that adds the C API for row-security, including calls to make it easy to wrap any relation in a dynamically created or stored updatable security barrier subquery during rewrite. - Produce and commit a patch series implementing the syntax, catalog tables / catalog changes, documentation, etc for row-security that uses this C API and commit it to core. SEPostgreSQL RLS can then be built on top of the same API, using the same core support. Thoughts? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
