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.
Quoting from your other message:
> We do not consider that a short coming, anyone who needs to hide
> existence of files needs to set up their directory structure to
> disallow read/search/create on the directories they aren't allowed to
> discover filenames in.
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what SEPostgres tries to do.
regards, tom lane
