database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-17 17:02:08 +03:00
Code Activity

Last-minute updates for release notes.

Browse Source 
Security: CVE-2019-10129, CVE-2019-10130
This commit is contained in:
Tom Lane
2019-05-06 12:45:59 -04:00
parent 40353bcc67
commit 585e8ffd19
1 changed files with 39 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
doc/src/sgml/release-10.sgml
View File

@ -33,6 +33,28 @@
<itemizedlist> <itemizedlist>
<listitem>
<para>
Prevent row-level security policies from being bypassed via
selectivity estimators (Dean Rasheed)
</para>
<para>
Some of the planner's selectivity estimators apply user-defined
operators to values found in <structname>pg_statistic</structname>
(e.g., most-common values). A leaky operator therefore can disclose
some of the entries in a data column, even if the calling user lacks
permission to read that column. In CVE-2017-7484 we added
restrictions to forestall that, but we failed to consider the
effects of row-level security. A user who has SQL permission to
read a column, but who is forbidden to see certain rows due to RLS
policy, might still learn something about those rows' contents via a
leaky operator. This patch further tightens the rules, allowing
leaky operators to be applied to statistics data only when there is
no relevant RLS policy. (CVE-2019-10130)
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Avoid catalog corruption when a temporary table with <literal>ON Avoid catalog corruption when a temporary table with <literal>ON
@ -263,6 +285,23 @@
</para> </para>
</listitem> </listitem>
<listitem>
<para>
Check the appropriate user's permissions when enforcing rules about
letting a leaky operator see <structname>pg_statistic</structname>
data (Dean Rasheed)
</para>
<para>
When an underlying table is being accessed via a view, consider the
privileges of the view owner while deciding whether leaky operators
may be applied to the table's statistics data, rather than the
privileges of the user making the query. This makes the planner's
rules about what data is visible match up with the executor's,
avoiding unnecessarily-poor plans.
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Speed up planning when there are many equality conditions and many Speed up planning when there are many equality conditions and many