On 25/10/11 11:36, David Johnston wrote: > Except database roles cannot strictly enforce row-level security (i.e., > multiple-tenant) which is the goal of this setup.
Ah, yes, if theyr'e relying on _row_ level security then that's very much the case. I misread their post as suggesting that they had different tables for different clients, rather than tables that mix different clients' data. Declarative row-level security (row ownership) would be really nice... here's hoping the SELinux work can be extended to support a simpler, OS-agnostic non-SELinux-based row-level RBAC mechanism. I'd still use SET ROLE where possible, and rely on SECURITY DEFINER stored procs in cases where clients' data is mixed in a table so you need to filter it programmatically. Then I'd wrap those procs in a view so they were transparent and looked like tables, so once row-level security is implemented you could switch to that without the app caring. -- Craig Ringer -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
