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
-
Add security checks to the multivariate MCV estimation code.
- d7f8d26d9f4c 12.0 landed
-
Add pg_stats_ext view for extended statistics
- aa087ec64f70 12.0 landed
-
Rework the pg_statistic_ext catalog
- 6cbfb784c3c9 12.0 landed