[v9.2] Leaky view and RLS - Mailing list pgsql-hackers

I'd like to summarize expected issues corresponding to leaky-view and RLS
towards v9.2, and PGcon2011/Developer Meeting.

We already made consensus the leaky-view is a problem to be fixed previous
to the row-level security feature.

We know several ways to leak/infer contents of tuples to be invisible using
a view that is defined to row-level security purpose.

[1] User defined functions with small-cost and side-effects (E.g error message)

If these functions are appended to WHERE clause, it may be executed earlier
than functions to be performed as row-level security policy of security views.
These function can take arguments that references either visible or invisible
tuples, so functions with side-effects enables to leak the contents of invisible
tuples, when it was invoked earlier than conditions to filter out.

[2] Iteration in proving PK/FK or UNIQUE constratins

This type of iteration enables to estimate invisible values. E.g, fails to insert
a tuple with a particular primary-key gives us a hint of existence of invisible
tuple. We made consensus that RLS does not handle this type of scenario called as
covert-channels. The point is user cannot see the hidden value directly.

[3] Reference to statistics delivered from table contents

One example was selectivity-estimator function; Tom mentioned about before.
The pg_statistic holds statistical information delivered from table contents,
so it may help users to infer the contents using its histograms.
The discussion didn't get hot at that time. However, the point of mine is same
as the reason why we don't handle covert-channels.
The statistical is irreversible translation from the original data, so we need
an intelligence process to infer them, not a direct data reference.


We also had a discussion about a principle what type of scenarios should be
considered as problem.
One was that we didn't consider it is not a problem if a function internally
references invisible rows, as long as it consumes them internally. Thus, we
considered index-access-methods can be launched earlier than functions to
filter out violated rows.
Second was that we didn't consider it is not a problem if RLS allows users
to infer invisible rows from the circumstances, as long as it is not possible
to dump invisible data directly, because its bandwidth to leak information
was quite slow. So, we decided not to handle covert-channel such as iteration
of PK/FK proving in RLS.

I still think the scenario [1] is the only problem to be solved prior to RLS
features. The scenario [2] and [3] don't allow to leak the original data
directly. In addition, the estimator function mentioned in [3] just references
statistical data internally. It is same situation with index-access-method.

Please give us the points at issue, if I now overlooked.

Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kaigai@eu.nec.com>