Richard Huxton wrote:
> Greg Smith wrote:
>> 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,
>
> As far as I can tell this is the case however you hide the information.
> If you implemented it with views you'll have the same issue. If you hide
> the existence of project p_id="TOPSECRET01" and people can run inserts
> then they can spot it. Likewise, it you have fkey references to the row
> then deletions can be used to spot it.
>
It is a covert channel discussion.
At least, SE-PostgreSQL does not care about hiding its existence,
so it does not prevent user to infer the existence of a tuple
with same key value, using PK confliction.
(Please note that he must have a info about PK value or lucky
to make a key confliction.)
But, it enables to prevent unclassified user to read the tuple,
and him to know an info the tuple contains "p_id=TOPSECRET01" as
a result of this read action.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
