From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof? |
Date: | 2018-07-11 22:52:00 |
Message-ID: | 11560.1531349520@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> I propose to run through the system operator classes, find any for which
> the comparison function isn't marked leakproof but the operators are,
> and fix them. This is clearly appropriate for HEAD and maybe it's not
> too late to force an initdb for v11 --- thoughts?
I did that for the built-in btree opclasses. I decided that it's probably
not worth forcing an initdb in v11 for, though. In principle, losing
selectivity estimates because of non-leakproof functions should only
happen in queries that are going to fail at runtime anyway. The real
problem that ought to be addressed and perhaps back-patched is this:
> Another question that could be raised is why we are refusing to use
> stats for a child table when the caller has select on the parent.
> It's completely trivial to extract data from a child table if you
> have select on the parent, so it seems like we are checking the
> wrong table's privileges.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mai Peng | 2018-07-11 22:56:34 | Segfault logical replication PG 10.4 |
Previous Message | Thomas Munro | 2018-07-11 22:31:46 | Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS) |