2012/12/12 Tom Lane <tgl@sss.pgh.pa.us>:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> Currently, ANALYZE collects data on all columns and stores these
>> samples in pg_statistic where they can be seen via the view pg_stats.
>
> Only if you have appropriate privileges.
>
>> In some cases we have data that is private and we do not wish others
>> to see it, such as patient names. This becomes more important when we
>> have row security.
>
>> Perhaps that data can be protected, but it would be even better if we
>> simply didn't store value-revealing statistic data at all.
>
> SET STATISTICS 0 seems like a sufficient solution for people who don't
> trust the have_column_privilege() protection in the pg_stats view.
>
> In practice I think this is a waste of time, though. Anyone who can
> bypass the view restriction can probably just read the original table.
>
> (I suppose we could consider marking pg_stats as a security_barrier
> view to make this even safer. Not sure it's worth the trouble though;
> the interesting columns are anyarray so it's hard to do much with them
> mechanically.)
>
I also agree with Tom's opinion. Even though it does not have security_barrier
flag now, unprivileged rows shall be filtered our with have_column_privilege().
It seems to me sufficient protection towards the scenario that allows users to
reference samples of contents within unprivileged columns.
Indeed, it is not sufficient protection when we have row security features;
for example, "SET STATISTICS 1000" to the table with less than 1000 rows
will eventually have full copy on pg_statistics catalog...
Unlike column, it does not save the origin of statistical data, so it
is not feasible
to control based on user's privilege. If we try to protect the
collected statistical
data (come from tables with row-security), an option is prohibits to access
entries relevant to relations with row-security. On the other hand, it
will affect
compatibility of third-party system monitoring tools that assumes pg_statistics
being visible...
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>