Tom Lane wrote: > Joshua Brindle <met...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
