begriffs open source - ai-pg/blob - full-docs/txt/planner-stats-security.txt

   1
   2 69.3. Planner Statistics and Security #
   3
   4    Access to the table pg_statistic is restricted to superusers, so that
   5    ordinary users cannot learn about the contents of the tables of other
   6    users from it. Some selectivity estimation functions will use a
   7    user-provided operator (either the operator appearing in the query or a
   8    related operator) to analyze the stored statistics. For example, in
   9    order to determine whether a stored most common value is applicable,
  10    the selectivity estimator will have to run the appropriate = operator
  11    to compare the constant in the query to the stored value. Thus the data
  12    in pg_statistic is potentially passed to user-defined operators. An
  13    appropriately crafted operator can intentionally leak the passed
  14    operands (for example, by logging them or writing them to a different
  15    table), or accidentally leak them by showing their values in error
  16    messages, in either case possibly exposing data from pg_statistic to a
  17    user who should not be able to see it.
  18
  19    In order to prevent this, the following applies to all built-in
  20    selectivity estimation functions. When planning a query, in order to be
  21    able to use stored statistics, the current user must either have SELECT
  22    privilege on the table or the involved columns, or the operator used
  23    must be LEAKPROOF (more accurately, the function that the operator is
  24    based on). If not, then the selectivity estimator will behave as if no
  25    statistics are available, and the planner will proceed with default or
  26    fall-back assumptions. The psql program's \do+ meta-command is useful
  27    to determine which operators are marked as leakproof.
  28
  29    If a user does not have the required privilege on the table or columns,
  30    then in many cases the query will ultimately receive a
  31    permission-denied error, in which case this mechanism is invisible in
  32    practice. But if the user is reading from a security-barrier view, then
  33    the planner might wish to check the statistics of an underlying table
  34    that is otherwise inaccessible to the user. In that case, the operator
  35    should be leakproof or the statistics will not be used. There is no
  36    direct feedback about that, except that the plan might be suboptimal.
  37    If one suspects that this is the case, one could try running the query
  38    as a more privileged user, to see if a different plan results.
  39
  40    This restriction applies only to cases where the planner would need to
  41    execute a user-defined operator on one or more values from
  42    pg_statistic. Thus the planner is permitted to use generic statistical
  43    information, such as the fraction of null values or the number of
  44    distinct values in a column, regardless of access privileges.
  45
  46    Selectivity estimation functions contained in third-party extensions
  47    that potentially operate on statistics with user-defined operators
  48    should follow the same security rules. Consult the PostgreSQL source
  49    code for guidance.