From 585e8ffd195d868f23318caaed6fd586f8d56a0e Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 6 May 2019 12:45:59 -0400
Subject: [PATCH] Last-minute updates for release notes.

Security: CVE-2019-10129, CVE-2019-10130
---
 doc/src/sgml/release-10.sgml | 39 ++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
index fc90f873d1a..d4e1e33c7ba 100644
--- a/doc/src/sgml/release-10.sgml
+++ b/doc/src/sgml/release-10.sgml
@@ -33,6 +33,28 @@
 
    <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>
      <para>
       Avoid catalog corruption when a temporary table with <literal>ON
@@ -263,6 +285,23 @@
      </para>
     </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>
      <para>
       Speed up planning when there are many equality conditions and many