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

On Mon, Oct 22, 2018 at 7:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > On Sat, Jul 14, 2018 at 11:29 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> >>> ... For
> >>> partitioning, we can rely on all the columns being inherited, but not
> >>> for plain inheritance.
>
> >> Uh, what?
>
> > But maybe for the case under question, that's irrelevant, because
> > we're only interested in access to inherited columns as those are the
> > only ones that can be accessed in queries via parent.
>
> Yeah, that's what I thought. It seems like it should be possible to base
> all stats access decisions off the table actually named in the query,
> because only columns appearing in that table could be referenced, and only
> that table's permissions actually get checked at runtime.
>
> I guess it's possible that a child table could have, say, an index on
> column X (inherited) and column Y (local) and that some aspect of costing
> might then be interested in the behavior of column Y, even though the
> query could only mention X not Y. But then we could fall back to the
> existing behavior.

Basically, if the relation is RELOPT_OTHER_MEMBER_REL, we can
recursively fetch its parent until we reach to the base relation
(which is actually named in the query). And, once we have the base
relation we can check ACL on that and set vardata->acl_ok accordingly.
Additionally, for getting the parent RTI we need to traverse
"root->append_rel_list". Another alternative could be that we can add
parent_rti member in RelOptInfo structure.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com