Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Fri, Sep 6, 2019 at 12:53 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >> Instead of falling back to the child, isn't it make more sense to
> >> check the permissions on the parent upto which we could translate (it
> >> may not be the root parent)?
>
> > Hmm, in that case, the parent up to which we might be able to
> > translate would still be a child and might have different permissions
> > than the table mentioned in the query (what's being called "root" in
> > this context). Would it be worth further complicating this code if
> > that's the case?
>
> I think that checking intermediate levels would be an actively bad idea
> --- it would make the behavior too confusing. We should preferably check
> the table actually named in the query, or if we can't then check the
> table we are using the stats of; nothing else.

Agreed.

> Another idea that we should consider, though, is to allow the access if
> *either* of those two tables allows it. The main reason that that's
> attractive is that it's certain not to break any case that works today.
> But also, it would mean that in many practical cases we'd not have to
> try to map Vars back up to the original parent, thus avoiding the
> performance penalty. (That is, check the target table as we do now,
> and only if we find it lacks permissions do we start mapping back.)

Ah, that sounds like a good idea.

Patch updated that way.

Thanks,
Amit