[v9.2] Fix leaky-view problem, part 2
От | Kohei Kaigai |
---|---|
Тема | [v9.2] Fix leaky-view problem, part 2 |
Дата | |
Msg-id | A9F5079BABDEE646AEBDB6831725762C556026245B@EUEXCLU01.EU.NEC.COM обсуждение исходный текст |
Ответ на | [v9.2] Leaky view and RLS (Kohei Kaigai <Kohei.Kaigai@EMEA.NEC.COM>) |
Ответы |
Re: [v9.2] Fix leaky-view problem, part 2
(Kohei KaiGai <kaigai@kaigai.gr.jp>)
|
Список | pgsql-hackers |
This patch enables to fix up leaky-view problem using qualifiers that reference only one-side of join-loop inside of viewdefinition. 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 distributethis qualifier into inside of the join-loop, even if it goes over the boundary of a subquery expanded from a viewfor 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 costis unignorable, because it also disables to utilize obviously indexable qualifiers such as (id=123), so this patch requiresusers 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 securitypurpose. 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 securityviews, 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 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>
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Robert HaasДата:
Сообщение: Re: reducing the overhead of frequent table locks - now, with WIP patch