Re: Multivariate MCV stats can leak data to unprivileged users - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Multivariate MCV stats can leak data to unprivileged users
Date
Msg-id 23229.1558275148@sss.pgh.pa.us
Whole thread Raw
In response to Re: Multivariate MCV stats can leak data to unprivileged users  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Multivariate MCV stats can leak data to unprivileged users
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> I think we shouldn't risk trying to get this into beta1, but let's try
> to get it done as soon as possible after that.

Agreed.

> \d pg_statistic_ext
>             Table "pg_catalog.pg_statistic_ext"
>     Column    |    Type    | Collation | Nullable | Default
> --------------+------------+-----------+----------+---------
>  oid          | oid        |           | not null |
>  stxrelid     | oid        |           | not null |
>  stxname      | name       |           | not null |
>  stxnamespace | oid        |           | not null |
>  stxowner     | oid        |           | not null |
>  stxkeys      | int2vector |           | not null |
>  stxkind      | "char"[]   |           | not null |
> Indexes:
>     "pg_statistic_ext_name_index" UNIQUE, btree (stxname, stxnamespace)
>     "pg_statistic_ext_oid_index" UNIQUE, btree (oid)
>     "pg_statistic_ext_relid_index" btree (stxrelid)

Check.

> \d pg_statistic_ext_data
>               Table "pg_catalog.pg_statistic_ext_data"
>      Column      |      Type       | Collation | Nullable | Default
> -----------------+-----------------+-----------+----------+---------
>  stxoid          | oid             |           | not null |
>  stxndistinct    | pg_ndistinct    | C         |          |
>  stxdependencies | pg_dependencies | C         |          |
>  stxmcv          | pg_mcv_list     | C         |          |
> Indexes:
>     "pg_statistic_ext_data_stxoid_index" UNIQUE, btree (stxoid)

I wonder ... another way we could potentially do this is

create table pg_statistic_ext_data(
    stxoid oid,  -- OID of owning pg_statistic_ext entry
    stxkind char, -- what kind of data
    stxdata bytea -- the data, in some format or other
);

The advantage of this way is that we'd not have to rejigger the
catalog's rowtype every time we think of a new kind of extended
stats.  The disadvantage is that manual inspection of the contents
of an entry would become much harder, for lack of any convenient
output function.  However, this whole exercise is mostly to prevent
casual manual inspection anyway :-(, so I wonder how much we care
about that.

Also, I assume there's going to be a user-accessible view that shows
a join of these tables, but only those rows that correspond to columns
the current user can read all of.  Should we give that view the name
pg_statistic_ext for maximum backward compatibility?  I'm not sure.
pg_dump would probably prefer it if the view is what has a new name,
but other clients might like the other way.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Create TOAST table only if AM needs
Next
From: Tom Lane
Date:
Subject: Re: Multivariate MCV stats can leak data to unprivileged users