It is incorrect.
It seems to me you confound a covert channel and granularity in access
controls. The purpose of row-level security is to provide users more
flexibility in access controls, not related to covert channels.
No, I claim it's you that's confounding the data hiding scheme with
row-level granular access controls.
Please note that SE-PostgreSQL does not make an assurance to hide
existence of invisible data. It ensures to prevent to read invisible
data via formal route, not a covert channel.
If a user types "SELECT count(*) from table" they should either get
the correct count of records from that table or get a permission
failure.
If they want to get the count of records for which they have read
access they should have to write "SELECT count(*) from table where
access_check(security_label, current_user())" or something like that.
SE-PostgreSQL considers "SELECT count(*) FROM table;" is an unconditional
select from a simple view with a condition.
However, there is no fundamental differences between filtering-out and
raising-error in the point where user cannot see invisible data via
formal route.
For example, a GUC variable to switch the behavior may be an option.
(It will be necessary to consider more for conclusion.)
But needless to say, my preference is filtering-out because it does
not require users to add additional conditions to avoid violated
tuples for each queries.
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
