Re: SE-PostgreSQL and row level security

>> 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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>