Re: Multivariate MCV stats can leak data to unprivileged users

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-05-19T18:14:54Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
>> No, wait, scratch that.  We could fold the three existing types
>> pg_ndistinct, pg_dependencies, pg_mcv_list into one new type, say
>> "pg_stats_ext_data", where the actual storage would need to have an
>> ID field (so we'd waste a byte or two duplicating the externally
>> visible stxkind field inside stxdata).  The output function for this
>> type is just a switch over the existing code.  The big advantage of
>> this way compared to the current approach is that adding a new
>> ext-stats type requires *zero* work with adding new catalog entries.
>> Just add another switch case in pg_stats_ext_data_out() and you're
>> done.

> The annoying thing is that this undoes the protections provided by special
> data types generated only in internally. It's not possible to generate
> e.g. pg_mcv_list values in user code (except for C code, at which points
> all bets are off anyway). By abandoning this and reverting to bytea anyone
> could craft a bytea and claim it's a statistic value.

That would have been true of the original proposal, but not of this
modified one.

			regards, tom lane



Commits

  1. Add security checks to the multivariate MCV estimation code.

  2. Add pg_stats_ext view for extended statistics

  3. Rework the pg_statistic_ext catalog