The simplified version of fix-leaky-view patch. The part of reloptions for views got splitted out into the part-0 patch, so it needs to be applied prior to this patch. Rest of logic to prevent unexpected pushing down across security barrier is not changed.
Thanks, 2011/6/6 Kohei Kaigai <kohei.kai...@emea.nec.com>: > This patch enables to fix up leaky-view problem using qualifiers that > reference only one-side of join-loop inside of view definition. > > The point of this scenario is criteria to distribute qualifiers of > scanning-plan distributed in distribute_qual_to_rels(). If and when a > qualifiers that reference only one-side of join-loop, the optimizer may > distribute this qualifier into inside of the join-loop, even if it goes over > the boundary of a subquery expanded from a view for row-level security. > This behavior allows us to reference whole of one-side of join-loop using > functions with side-effects. > The solution is quite simple; it prohibits to distribute qualifiers over the > boundary of subquery, however, performance cost is unignorable, because it > also disables to utilize obviously indexable qualifiers such as (id=123), so > this patch requires users a hint whether a particular view is for row-level > security, or not. > > This patch newly adds "CREATE SECURITY VIEW" statement that marks a flag to > show this view was defined for row-level security purpose. This flag shall be > stored as reloptions. > If this flag was set, the optimizer does not distribute qualifiers over the > boundary of subqueries expanded from security views, except for obviously > safe qualifiers. > (Right now, we consider built-in indexable operators are safe, but it might > be arguable.) > > It fixes up the scenario [2] 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 following criteria 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 problem to 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 scenario with 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 can make order reversal when > user-given qualifier has smaller cost than qualifiers to perform as security > policy inside of view. > In the result, these qualifiers can reference both of visible and invisible > tuples prior to the filtering by row-level security policy 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 good strategy to distribute this > qualifier into inside of the join-loop to minimize number of tuples to be > joined, from the viewpoint of performance. > However, it also makes order reversal when the join-loop is a part of view > definition that should perform row-level security policy. Then, these > exogenetic qualifiers may be executed prior to the filtering by row-level > security policy of the 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 if we 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 to the 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 have invisible tuples for > optimization. Here are two points to be considered. The one is purely > internal stuff may be able to reference invisible tuples, however, it is not > a problem as long as it does not leak them into end-users; such as index > access methods. The second is statistical or other form of date delivered > from invisible tuples. We can set up a table that contains data delivered > from invisible tuples using row-level triggers, however, it is quite a matter > of database administration. 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.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 > > -- KaiGai Kohei <kai...@kaigai.gr.jp>
pgsql-v9.2-fix-leaky-view-part-2.v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
