]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Add security checks to selectivity estimation functions
authorPeter Eisentraut <peter_e@gmx.net>
Fri, 5 May 2017 16:18:48 +0000 (12:18 -0400)
committerPeter Eisentraut <peter_e@gmx.net>
Mon, 8 May 2017 13:19:42 +0000 (09:19 -0400)
commitd035c1b970fe948c10773315a2f022204bc45df6
treea4647f96952975b52102e89a3cf20820551667ff
parentf79531ffd42f2d0e5c35d1dffbc2c2f2cd2086dc
Add security checks to selectivity estimation functions

Some selectivity estimation functions run user-supplied operators over
data obtained from pg_statistic without security checks, which allows
those operators to leak pg_statistic data without having privileges on
the underlying tables.  Fix by checking that one of the following is
satisfied: (1) the user has table or column privileges on the table
underlying the pg_statistic data, or (2) the function implementing the
user-supplied operator is leak-proof.  If neither is satisfied, planning
will proceed as if there are no statistics available.

At least one of these is satisfied in most cases in practice.  The only
situations that are negatively impacted are user-defined or
not-leak-proof operators on a security-barrier view.

Reported-by: Robert Haas <robertmhaas@gmail.com>
Author: Peter Eisentraut <peter_e@gmx.net>
Author: Tom Lane <tgl@sss.pgh.pa.us>

Security: CVE-2017-7484
doc/src/sgml/planstats.sgml
src/backend/utils/adt/array_selfuncs.c
src/backend/utils/adt/selfuncs.c
src/include/utils/selfuncs.h
src/test/regress/expected/privileges.out
src/test/regress/sql/privileges.sql