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

From Tom Lane
Subject Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Date
Msg-id 83025.1540217851@sss.pgh.pa.us
Whole thread Raw
In response to Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Sat, Jul 14, 2018 at 11:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.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.

            regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Side effect of CVE-2017-7484 fix?
Next
From: Jeremy Finzel
Date:
Subject: Changes to error handling for background worker initialization?