diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/src/sgml/planstats.sgml | 61 |
1 files changed, 61 insertions, 0 deletions
diff --git a/doc/src/sgml/planstats.sgml b/doc/src/sgml/planstats.sgml index f4430eb23cf..11580bfd228 100644 --- a/doc/src/sgml/planstats.sgml +++ b/doc/src/sgml/planstats.sgml @@ -582,4 +582,65 @@ EXPLAIN (ANALYZE, TIMING OFF) SELECT COUNT(*) FROM t GROUP BY a, b; </sect2> </sect1> + + <sect1 id="planner-stats-security"> + <title>Planner Statistics and Security</title> + + <para> + Access to the table <structname>pg_statistic</structname> is restricted to + superusers, so that ordinary users cannot learn about the contents of the + tables of other users from it. Some selectivity estimation functions will + use a user-provided operator (either the operator appearing in the query or + a related operator) to analyze the stored statistics. For example, in order + to determine whether a stored most common value is applicable, the + selectivity estimator will have to run the appropriate <literal>=</literal> + operator to compare the constant in the query to the stored value. + Thus the data in <structname>pg_statistic</structname> is potentially + passed to user-defined operators. An appropriately crafted operator can + intentionally leak the passed operands (for example, by logging them + or writing them to a different table), or accidentally leak them by showing + their values in error messages, in either case possibly exposing data from + <structname>pg_statistic</structname> to a user who should not be able to + see it. + </para> + + <para> + In order to prevent this, the following applies to all built-in selectivity + estimation functions. When planning a query, in order to be able to use + stored statistics, the current user must either + have <literal>SELECT</literal> privilege on the table or the involved + columns, or the operator used must be <literal>LEAKPROOF</literal> (more + accurately, the function that the operator is based on). If not, then the + selectivity estimator will behave as if no statistics are available, and + the planner will proceed with default or fall-back assumptions. + </para> + + <para> + If a user does not have the required privilege on the table or columns, + then in many cases the query will ultimately receive a permission-denied + error, in which case this mechanism is invisible in practice. But if the + user is reading from a security-barrier view, then the planner might wish + to check the statistics of an underlying table that is otherwise + inaccessible to the user. In that case, the operator should be leak-proof + or the statistics will not be used. There is no direct feedback about + that, except that the plan might be suboptimal. If one suspects that this + is the case, one could try running the query as a more privileged user, + to see if a different plan results. + </para> + + <para> + This restriction applies only to cases where the planner would need to + execute a user-defined operator on one or more values + from <structname>pg_statistic</structname>. Thus the planner is permitted + to use generic statistical information, such as the fraction of null values + or the number of distinct values in a column, regardless of access + privileges. + </para> + + <para> + Selectivity estimation functions contained in third-party extensions that + potentially operate on statistics with user-defined operators should follow + the same security rules. Consult the PostgreSQL source code for guidance. + </para> + </sect1> </chapter> |