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

On 2018/10/25 19:54, Dilip Kumar wrote:
> 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:
>>> 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.

Adding parent_rti would be a better idea [1]. I think that traversing
append_rel_list every time would be inefficient.

Thanks,
Amit

[1] I've named it inh_root_parent in one of the patches I'm working on
where I needed such a field (https://commitfest.postgresql.org/20/1778/)