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-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.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.kai...@emea.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
