[v9.2] Fix leaky-view problem, part 1 - Mailing list pgsql-hackers

This patch enables to fix up leaky-view problem using functions with tiny cost estimation scenario.

The point of this scenario is criteria to reorder qualifiers of scanning plan in order_qual_clauses(). The optimizer
maypull up simple subqueries into upper level, then its qualifier will get merged with ones in the upper level. When
executorscans a relation, qualifiers with smaller cost shall be executed earlier to minimize cost to filter out
invisibletuples. However, we know unpreferable side-effects when we use a view for row-level security. 
Even if a certain subquery rewritten from a view is defined for row-level security, a function with tiny cost appended
fromoutside of the view may executed earlier than qualifiers to perform as security policy of the view, as long as the
viewis enough simple and the supplied function has tiny cost. In the result, this function can see the arguments come
frominvisible tuples, and leak them into somewhere. 

The solution is quite simple. This patch enables to track original depth of qualifiers and modify criteria to sort
qualifiersin order_qual_clauses(). 
Even if a function with tiny cost is supplied from outside of views, the patched optimizer does not prioritize cost
estimationmore than the depth. 

It fixes up the scenario [1] in the bellow descriprions.

--------
The background of the leaky-view problem is well summarized at:
  http://wiki.postgresql.org/wiki/RLS

We had discussed several scenarios in v9.1 development cycle, and the last developer meeting. We almost concluded the
followingcriteria to characterize whether a leak-view scenario is problematic to be fixed, or not. 
 * If unprived user can directly reference contents of invisible tuples, it is a problem to be fixed.
 * As long as contents of invisible tuples are consumed by internal stuff (eg, index-access method), it is not a
problemto be fixed. 

Thus, the scenario [1] and [2] are problematic to be fixed, but [3] and [4] are not. So, I'll try to fix up these two
scenariowith the patch part-1 amd part-2. 

[1] unexpected reorder of functions with tiny-cost and side-effects

Qualifiers of WHERE or JOIN ... IN clause shall be sorted by estimated cost, not depth of nest level. Thus, this logic
canmake order reversal when user-given qualifier has smaller cost than qualifiers to perform as security policy inside
ofview. 
In the result, these qualifiers can reference both of visible and invisible tuples prior to the filtering by row-level
securitypolicy of the view. Thus, this behavior can be used to leak contents of invisible tuples. 


[2] unexpected push-down of functions with side-effect into join-loop

If arguments of qualifier being appended on outside of join-loop references only one-side of the join-loop, it is a
goodstrategy to distribute this qualifier into inside of the join-loop to minimize number of tuples to be joined, from
theviewpoint of performance. 
However, it also makes order reversal when the join-loop is a part of view definition that should perform row-level
securitypolicy. Then, these exogenetic qualifiers may be executed prior to the filtering by row-level security policy
ofthe view. Thus, this behavior can be used to leak contents of invisible tuple. 


[3] estimation of hidden value using iteration of PK/FK proves

Due to the nature of PK/FK constraints, we can infer existence of key values being stored within invisible tuple, even
ifwe never allows users to reference contents of invisible tuples. 
We commonly call this type of information leaks "covert-channel", and it is basically impossible to prevent according
tothe previous security research, however, its risk is also relatively small because of slow bandwidth to leak. 
We already made consensus this scenario is not a problem to be fixed.


[4] estimation of hidden value using statistics

One example was selectivity-estimator function; that may reference statistical information delivered from the tables
haveinvisible tuples for optimization. Here are two points to be considered. The one is purely internal stuff may be
ableto reference invisible tuples, however, it is not a problem as long as it does not leak them into end-users; such
asindex access methods. The second is statistical or other form of date delivered from invisible tuples. We can set up
atable that contains data delivered from invisible tuples using row-level triggers, however, it is quite a matter of
databaseadministration. Unless owner of tables set up such a leakable configuration, other users cannot reference them. 

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