From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Multivariate MCV stats can leak data to unprivileged users
Date: Mon, 20 May 2019 00:44:59 +0200
Message-ID: <20190519224459.7dsdnv5gsfmnm4em@development> (raw)
In-Reply-To: <2509.1558289694@sss.pgh.pa.us>
References: <20190518190042.2y33h4toxk4fxv5t@development>
<568.1558208711@sss.pgh.pa.us>
<20190518232812.qpnjmydlx3uzzsj7@development>
<20866.1558223060@sss.pgh.pa.us>
<20190518234841.GE6197@tamriel.snowman.net>
<CAEZATCUcoAKrn-1NFkDN7md-wt6CQev0JXa+Tv31T9Jjkxgx5Q@mail.gmail.com>
<23229.1558275148@sss.pgh.pa.us>
<23772.1558276123@sss.pgh.pa.us>
<20190519173845.tgf7ku3vigwgndn5@development>
<2509.1558289694@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, tgl@sss.pgh.pa.us, dean.a.rasheed@gmail.com, sfrost@snowman.net, andres@anarazel.de
Subject: Re: Multivariate MCV stats can leak data to unprivileged users
In-Reply-To: <20190519224459.7dsdnv5gsfmnm4em@development>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox