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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Date: 2018-10-22 14:17:31
Message-ID: 83025.1540217851@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2018-10-22 14:36:07 Changes to error handling for background worker initialization?
Previous Message David Fetter 2018-10-22 14:10:32 Re: Side effect of CVE-2017-7484 fix?