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