On Mon, Nov 28, 2016 at 6:55 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
>> [...]
>> + Additional rules will be needed to support safe handling of join quals
>> + when there is a mix of security levels among join quals; for example, it
>> + will be necessary to prevent leaky higher-security-level quals from being
>> + evaluated at a lower join level than other quals of lower security level.
>> + Currently there is no need to consider that since security-prioritized
>> + quals can only be single-table restriction quals coming from RLS policies
>> + or security-barrier views, and thus enforcement only needs to happen at
>> + the table scan level. With such extra rules, it should be possible to let
>> + security-barrier views be flattened into the parent query, allowing more
>> + flexibility of planning while still preserving required ordering of qual
>> + evaluation. But that will come later.
>
> Are you thinking that we will be able to remove the cut-out in
> is_simple_subquery() which currently punts whenever an RTE is marked as
> security_barrier? That would certainly be excellent as, currently, even
> if everything involved is leakproof, we may end up with a poor choice of
> plan because the join in the security barrier view must be performed
> first. Consider a case where we have two relativly large tables being
> joined together in a security barrier view, but a join from outside
> which is against a small table. A better plan would generally be to
> join with the smaller table first and then join the resulting small set
> against the remaining large table.
We have to be careful that we don't introduce new security holes while
we're improving the plans. I guess this would be OK if the table, its
target list, and its quals all happened to be leakproof, but otherwise
not. Or am I confused?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company