Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Nov 28, 2016 at 6:55 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> 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?
The plan I have in mind --- it's not implemented in this patch --- is to
fix things so that the "lower security_level quals must be evaluated
first" rule applies to join quals. It should then be possible to allow
flattening of security-barrier views without security holes.
One part of that would be to teach distribute_qual_to_rels about it
so that less-secure quals can't fall to a lower join level than
more-secure quals. I think that's relatively straightforward, though
I've not tried to do it yet.
A bigger issue is that we don't have security_level attached to individual
quals at the time when view flattening gets done. We'd need some other
way of maintaining the distinction between security quals and regular
quals between there and where RestrictInfos get built. I don't have a good
idea about how to do that yet, but it doesn't seem insoluble.
regards, tom lane