Re: Improving RLS planning

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> 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?

I agree that we need to be careful that we don't introduce security
holes.

Also, I do think it would be nice if we could arrange to have the same
plan in the security-barrier case as is in the no-security-barrier case
when there are no leaky functions involved.

That said, I believe this becomes a similar order-of-operations question
to make sure that values are never exposed to leaky functions until
after all necessary filtering has been performed.  In particular, when
considering joins, if all of the join operators are leakproof then we
could possibly reorder the joins however we choose, as long as anything
leaky is performed after all joins required for security correctness are
performed and all security barrier quals are applied.

Thanks!

Stephen