From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | David Johnston <polobo(at)yahoo(dot)com> |
Cc: | Brice André <brice(at)famille-andre(dot)be>, "pgsql-sql(at)postgresql(dot)org" <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Handling mutliple clients access with views |
Date: | 2011-10-25 03:50:16 |
Message-ID: | 4EA631F8.1080508@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | bricklen | 2011-10-25 03:52:56 | Re: Handling mutliple clients access with views |
Previous Message | David Johnston | 2011-10-25 03:36:33 | Re: Handling mutliple clients access with views |