Tom Lane wrote:
> Joshua Brindle <method@manicmethod.com> writes:
>> Tom Lane wrote:
>>> Right, which is why it's bad for something like a foreign key constraint
>>> to expose the fact that the row does exist after all.
>
>> Once again, this is not an issue for us.
>
> Yes it is an issue; claiming it isn't doesn't make it so. You just
> stated, in effect, that you don't implement data hiding in the
> filesystem because it would break standard Unix filesystem semantics.
> How is that consistent with your opinion that it's okay to break
> standard SQL semantics in order to implement data hiding in a database?
>
> The question of whether there is a covert channel is only a small part
> of my complaint here. If it's the judgement of security experts that
> that's an acceptable thing, that's fine, it's their turf. But SQL
> behavior is my turf, and I'm not happy with discarding fundamental
> semantic properties.
Do you forget a GUC option: sepostgresql_row_leve = on/off ?
It was a requirement from Simon Riggs at Oct 2008, IIRC.
Its original purpose is to reduce storage consumption due to
the security label of each tuples, however, it can allow users
to choose the granularity of access controls in finally.
I can understand you have a complaint about covert channels
via PK/FK due to the row-level granularity.
However, in other hand, we can already see a commercial
producet which provides row-level access controls without
any cares about covert channels.
It shows a fact that not negligible number of users accept
row-level granularity, even if it has covert channels.
What is needed is an explicit documentation about covert
channels and providing a few options to users.
It is not a reasonable stance to deny anything due to a
single item which is acceptable some of people, at least.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>