Re: 8.4 release planning

On Wed, 28 Jan 2009, KaiGai Kohei wrote:

> It shows a fact that not negligible number of users accept row-level 
> granularity, even if it has covert channels.

From my read of the examples that Chad provided, keeping the existence of 
things secret from complete outsiders doesn't look like the prime concern. 
There's plenty of these applications floating around where everyone 
involved is cleared, but to different levels and projects.

The person working on a "secret" project knows perfectly well that there 
are also "top secret" projects floating around they aren't cleared for, 
and that's OK.  They'll probably detect their existence by the doors 
they're not allowed through long before they notice that database rows are 
missing. If you're able to sit in front of a computer that's capable of 
even reaching this information but aren't supposed to be anywhere near it, 
that means there's been a physical security breach.

Where I suspect this is all is going to settle down into is that if 1) the 
SE GUC is on and 2) one of the tables in a join has rows filtered, then 
you can expect that a) it's possible that the result will leak 
information, which certainly need to be documented, and b) the 
optimizations Tom mentioned that "assume foreign key constraints hold" 
will not be possible to implement, so performance will suck compared to a 
similar situation in an unsecured environment.  And all that may very well 
be just fine as far as the people wanting to build applications with 
SEPostgreSQL are concerned.  It will just hint toward using a schema 
design with table-level controls instead if you care about high 
performance on that style of join.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD