Re: [v9.2] Leaky view and RLS

Oops, I overlooked a scenario that we discussed before.

[4] Unexpected qualifier distributions into inside of join-loop
If a qualifier being appended on outside of join-loop references only one-side of the join,
the optimizer will unexpectedly distribute it into inside of the join-loop.
In the result, these exogenetic qualifiers may be evaluated earlier than security policy
functions inside of a view that contains join.

It also allows unprivileged users to reference contents of invisible tuples, so it shall be
a problem to be fixed up according to the principle I described below.

As a reference information, we had discussed the following approach:
We tried to extend CREATE VIEW statement to accept SECURITY attribute to prevent unexpected
qualifier distribution into inside of join-loop originated from security views.
In addition, we also tried to add a variable to track original nest-level of qualifiers to
order qualifiers in WHERE clause. It enabled to fix up [1] and [4].

However, the [3] was pointed out during the discussion and I was not sure where was the
essence of this issue. So, the patch was returned with feedbacks, then it got postponed
to v9.2 to solve this problem.

Thanks,

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of
> Kohei Kaigai
> Sent: 10. Mai 2011 12:56
> To: Robert Haas; Stephen Frost; Heikki Linnakangas; Tom Lane
> Cc: pgsql-hackers
> Subject: [HACKERS] [v9.2] Leaky view and RLS
>
> 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.
>
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei(dot)kaigai(at)emea(dot)nec(dot)com>