Tom Lane wrote:
Josh Berkus <j...@agliodbs.com> writes:
Stephen Frost wrote:
It does seem weird to simply omit records rather than throw an error
The presumption is that if you know the data exists but can't access it
directly, you'll use indirect methods to derive what it is. But if you
don't even know it exists, then you won't look for it.
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. We would much rather have a database
that allows you to hide data from unauthorized clients using a mandatory policy
than one that does nothing because you couldn't close some covert channels.
I'll repeat what I said in an earlier email, SELinux doesn't (and can't) address
all covert channels in Linux, and that is fine as long as it is understood and
documented (which is part of the evaluation process).
There's a level above that which I don't think SEPostgres implements,
which is data substitution, in which you see different data according to
what security level you are. While this may seem insane for a business
application, for military-support applications it makes some sense.
I think it might be possible to build such a thing using views, but I
agree that the patch doesn't give it to you for free.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
