Re: Multivariate MCV stats can leak data to unprivileged users
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-19T22:44:59Z
Lists: pgsql-hackers
On Sun, May 19, 2019 at 02:14:54PM -0400, Tom Lane wrote: >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. > Oh, right. It still has the disadvantage that it obfuscates the actual data stored in the pg_stats_ext_data (or whatever would it be called), so e.g. functions would have to do additional checks to make sure it actually is the right statistic type. For example pg_mcv_list_items() could not rely on receiving pg_mcv_list values, as per the signature, but would have to check the value. Of course, I don't expect to have too many such functions, but overall this approach with a single type feels a bit too like EAV to my taste. I think Dean is right we should not expect many more statistic types than what we already have - a histogram, and perhaps one or two more. So I agree with Dean the current design with separate statistic types is not such a big issue. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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