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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2018-07-11T22:52:00Z
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


Commits

  1. Allow access to child table statistics if user can read parent table.

  2. Mark built-in btree comparison functions as leakproof where it's safe.