Message-ID: <4EA631F8.1080508@ringerc.id.au>
Date: Tue, 25 Oct 2011 11:50:16 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9
MIME-Version: 1.0
To: David Johnston <polobo@yahoo.com>
CC: =?UTF-8?B?QnJpY2UgQW5kcsOp?= <brice@famille-andre.be>,
	"pgsql-sql@postgresql.org" <pgsql-sql@postgresql.org>
Subject: Re: Handling mutliple clients access with views
References: 
 <CAOBG12kFTaWUDHU-puJuDK5wQUZ=hdkFBbN1Ku9HUA8_qp0BAg@mail.gmail.com>
	<4EA62500.9070000@ringerc.id.au>
	<34C216F7-8D8D-4F18-A693-AAF922BF6672@yahoo.com>
In-Reply-To: <34C216F7-8D8D-4F18-A693-AAF922BF6672@yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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