Last-minute updates for release notes.

Security: CVE-2018-1058

5 files changed, 403 insertions, 7 deletions

diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
index 100301bd4e0..19f2410c350 100644
--- a/doc/src/sgml/release-10.sgml
+++ b/doc/src/sgml/release-10.sgml
@@ -23,7 +23,23 @@
    </para>
 
    <para>
-    However, if you are upgrading from a version earlier than 10.2,
+    However, if you run an installation in which not all users are mutually
+    trusting, or if you maintain an application or extension that is
+    intended for use in arbitrary situations, it is strongly recommended
+    that you read the documentation changes described in the first changelog
+    entry below, and take suitable steps to ensure that your installation or
+    code is secure.
+   </para>
+
+   <para>
+    Also, the changes described in the second changelog entry below may
+    cause functions used in index expressions or materialized views to fail
+    during auto-analyze, or when reloading from a dump.  After upgrading,
+    monitor the server logs for such problems, and fix affected functions.
+   </para>
+
+   <para>
+    Also, if you are upgrading from a version earlier than 10.2,
     see <xref linkend="release-10-2">.
    </para>
   </sect2>
@@ -35,6 +51,92 @@
 
     <listitem>
 <!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [5770172cb] 2018-02-26 07:39:44 -0800
+Branch: REL_10_STABLE [ee0d1966e] 2018-02-26 07:39:47 -0800
+Branch: REL9_6_STABLE [70396dbe3] 2018-02-26 07:39:48 -0800
+Branch: REL9_5_STABLE [1f47ea7b8] 2018-02-26 07:39:48 -0800
+Branch: REL9_4_STABLE [f28955e38] 2018-02-26 07:39:48 -0800
+Branch: REL9_3_STABLE [41ee473a4] 2018-02-26 07:39:48 -0800
+-->
+     <para>
+      Document how to configure installations and applications to guard
+      against search-path-dependent trojan-horse attacks from other users
+      (Noah Misch)
+     </para>
+
+     <para>
+      Using a <varname>search_path</varname> setting that includes any
+      schemas writable by a hostile user enables that user to capture
+      control of queries and then run arbitrary SQL code with the
+      permissions of the attacked user.  While it is possible to write
+      queries that are proof against such hijacking, it is notationally
+      tedious, and it's very easy to overlook holes.  Therefore, we now
+      recommend configurations in which no untrusted schemas appear in
+      one's search path.  Relevant documentation appears in
+      <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+      <xref linkend="libpq-connect"> (for application authors),
+      <xref linkend="extend-extensions-style">  (for extension authors), and
+      <xref linkend="sql-createfunction"> (for authors
+      of <literal>SECURITY DEFINER</literal> functions).
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [582edc369] 2018-02-26 07:39:44 -0800
+Branch: REL_10_STABLE [10d598354] 2018-02-26 07:39:47 -0800
+Branch: REL9_6_STABLE [e170b8c8c] 2018-02-26 07:39:48 -0800
+Branch: REL9_5_STABLE [91f3ffc52] 2018-02-26 07:39:48 -0800
+Branch: REL9_4_STABLE [928bca1a3] 2018-02-26 07:39:48 -0800
+Branch: REL9_3_STABLE [3db38b0ce] 2018-02-26 07:39:48 -0800
+Author: Noah Misch <noah@leadboat.com>
+Branch: REL9_4_STABLE [461c32b55] 2018-02-26 07:39:48 -0800
+Branch: REL9_3_STABLE [de8ffd666] 2018-02-26 07:39:48 -0800
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [3d2aed664] 2018-02-26 10:18:21 -0500
+Branch: REL_10_STABLE [b8a2908f0] 2018-02-26 10:18:22 -0500
+Branch: REL9_6_STABLE [815172ba8] 2018-02-26 10:18:22 -0500
+Branch: REL9_5_STABLE [a8fc37a63] 2018-02-26 10:18:22 -0500
+Branch: REL9_4_STABLE [9f6e5296a] 2018-02-26 10:18:22 -0500
+Branch: REL9_3_STABLE [fe8b95b7e] 2018-02-26 10:18:22 -0500
+-->
+     <para>
+      Avoid use of insecure <varname>search_path</varname> settings
+      in <application>pg_dump</application> and other client programs
+      (Noah Misch, Tom Lane)
+     </para>
+
+     <para>
+      <application>pg_dump</application>,
+      <application>pg_upgrade</application>,
+      <application>vacuumdb</application> and
+      other <productname>PostgreSQL</productname>-provided applications were
+      themselves vulnerable to the type of hijacking described in the previous
+      changelog entry; since these applications are commonly run by
+      superusers, they present particularly attractive targets.  To make them
+      secure whether or not the installation as a whole has been secured,
+      modify them to include only the <structname>pg_catalog</structname>
+      schema in their <varname>search_path</varname> settings.
+      Autovacuum worker processes now do the same, as well.
+     </para>
+
+     <para>
+      In cases where user-provided functions are indirectly executed by
+      these programs &mdash; for example, user-provided functions in index
+      expressions &mdash; the tighter <varname>search_path</varname> may
+      result in errors, which will need to be corrected by adjusting those
+      user-provided functions to not assume anything about what search path
+      they are invoked under.  That has always been good practice, but now
+      it will be necessary for correct behavior.
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+<!--
 Author: Peter Eisentraut <peter_e@gmx.net>
 Branch: master [bc1adc651] 2018-02-23 22:13:21 -0500
 Branch: REL_10_STABLE [b9bf23abb] 2018-02-23 22:09:26 -0500
@@ -50,8 +152,6 @@ Branch: REL_10_STABLE [b9bf23abb] 2018-02-23 22:09:26 -0500
       and <structname>information_schema</structname> tables, which are
       supposed to be omitted from the change stream.
      </para>
-     <para>
-     </para>
     </listitem>
 
     <listitem>
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 9e470f59c73..ead56444d9f 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -23,7 +23,23 @@
    </para>
 
    <para>
-    However, if you are upgrading from a version earlier than 9.3.18,
+    However, if you run an installation in which not all users are mutually
+    trusting, or if you maintain an application or extension that is
+    intended for use in arbitrary situations, it is strongly recommended
+    that you read the documentation changes described in the first changelog
+    entry below, and take suitable steps to ensure that your installation or
+    code is secure.
+   </para>
+
+   <para>
+    Also, the changes described in the second changelog entry below may
+    cause functions used in index expressions or materialized views to fail
+    during auto-analyze, or when reloading from a dump.  After upgrading,
+    monitor the server logs for such problems, and fix affected functions.
+   </para>
+
+   <para>
+    Also, if you are upgrading from a version earlier than 9.3.18,
     see <xref linkend="release-9-3-18">.
    </para>
   </sect2>
@@ -35,6 +51,64 @@
 
     <listitem>
      <para>
+      Document how to configure installations and applications to guard
+      against search-path-dependent trojan-horse attacks from other users
+      (Noah Misch)
+     </para>
+
+     <para>
+      Using a <varname>search_path</varname> setting that includes any
+      schemas writable by a hostile user enables that user to capture
+      control of queries and then run arbitrary SQL code with the
+      permissions of the attacked user.  While it is possible to write
+      queries that are proof against such hijacking, it is notationally
+      tedious, and it's very easy to overlook holes.  Therefore, we now
+      recommend configurations in which no untrusted schemas appear in
+      one's search path.  Relevant documentation appears in
+      <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+      <xref linkend="libpq-connect"> (for application authors),
+      <xref linkend="extend-extensions-style">  (for extension authors), and
+      <xref linkend="sql-createfunction"> (for authors
+      of <literal>SECURITY DEFINER</literal> functions).
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid use of insecure <varname>search_path</varname> settings
+      in <application>pg_dump</application> and other client programs
+      (Noah Misch, Tom Lane)
+     </para>
+
+     <para>
+      <application>pg_dump</application>,
+      <application>pg_upgrade</application>,
+      <application>vacuumdb</application> and
+      other <productname>PostgreSQL</productname>-provided applications were
+      themselves vulnerable to the type of hijacking described in the previous
+      changelog entry; since these applications are commonly run by
+      superusers, they present particularly attractive targets.  To make them
+      secure whether or not the installation as a whole has been secured,
+      modify them to include only the <structname>pg_catalog</structname>
+      schema in their <varname>search_path</varname> settings.
+      Autovacuum worker processes now do the same, as well.
+     </para>
+
+     <para>
+      In cases where user-provided functions are indirectly executed by
+      these programs &mdash; for example, user-provided functions in index
+      expressions &mdash; the tighter <varname>search_path</varname> may
+      result in errors, which will need to be corrected by adjusting those
+      user-provided functions to not assume anything about what search path
+      they are invoked under.  That has always been good practice, but now
+      it will be necessary for correct behavior.
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
       Fix misbehavior of concurrent-update rechecks with CTE references
       appearing in subplans (Tom Lane)
      </para>
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index a823c8f2614..c7e90962639 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -23,7 +23,23 @@
    </para>
 
    <para>
-    However, if you are upgrading from a version earlier than 9.4.13,
+    However, if you run an installation in which not all users are mutually
+    trusting, or if you maintain an application or extension that is
+    intended for use in arbitrary situations, it is strongly recommended
+    that you read the documentation changes described in the first changelog
+    entry below, and take suitable steps to ensure that your installation or
+    code is secure.
+   </para>
+
+   <para>
+    Also, the changes described in the second changelog entry below may
+    cause functions used in index expressions or materialized views to fail
+    during auto-analyze, or when reloading from a dump.  After upgrading,
+    monitor the server logs for such problems, and fix affected functions.
+   </para>
+
+   <para>
+    Also, if you are upgrading from a version earlier than 9.4.13,
     see <xref linkend="release-9-4-13">.
    </para>
   </sect2>
@@ -35,6 +51,64 @@
 
     <listitem>
      <para>
+      Document how to configure installations and applications to guard
+      against search-path-dependent trojan-horse attacks from other users
+      (Noah Misch)
+     </para>
+
+     <para>
+      Using a <varname>search_path</varname> setting that includes any
+      schemas writable by a hostile user enables that user to capture
+      control of queries and then run arbitrary SQL code with the
+      permissions of the attacked user.  While it is possible to write
+      queries that are proof against such hijacking, it is notationally
+      tedious, and it's very easy to overlook holes.  Therefore, we now
+      recommend configurations in which no untrusted schemas appear in
+      one's search path.  Relevant documentation appears in
+      <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+      <xref linkend="libpq-connect"> (for application authors),
+      <xref linkend="extend-extensions-style">  (for extension authors), and
+      <xref linkend="sql-createfunction"> (for authors
+      of <literal>SECURITY DEFINER</literal> functions).
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid use of insecure <varname>search_path</varname> settings
+      in <application>pg_dump</application> and other client programs
+      (Noah Misch, Tom Lane)
+     </para>
+
+     <para>
+      <application>pg_dump</application>,
+      <application>pg_upgrade</application>,
+      <application>vacuumdb</application> and
+      other <productname>PostgreSQL</productname>-provided applications were
+      themselves vulnerable to the type of hijacking described in the previous
+      changelog entry; since these applications are commonly run by
+      superusers, they present particularly attractive targets.  To make them
+      secure whether or not the installation as a whole has been secured,
+      modify them to include only the <structname>pg_catalog</structname>
+      schema in their <varname>search_path</varname> settings.
+      Autovacuum worker processes now do the same, as well.
+     </para>
+
+     <para>
+      In cases where user-provided functions are indirectly executed by
+      these programs &mdash; for example, user-provided functions in index
+      expressions &mdash; the tighter <varname>search_path</varname> may
+      result in errors, which will need to be corrected by adjusting those
+      user-provided functions to not assume anything about what search path
+      they are invoked under.  That has always been good practice, but now
+      it will be necessary for correct behavior.
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
       Fix misbehavior of concurrent-update rechecks with CTE references
       appearing in subplans (Tom Lane)
      </para>
diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml
index 22b4964ccaa..e5e71a6af60 100644
--- a/doc/src/sgml/release-9.5.sgml
+++ b/doc/src/sgml/release-9.5.sgml
@@ -23,7 +23,23 @@
    </para>
 
    <para>
-    However, if you are upgrading from a version earlier than 9.5.10,
+    However, if you run an installation in which not all users are mutually
+    trusting, or if you maintain an application or extension that is
+    intended for use in arbitrary situations, it is strongly recommended
+    that you read the documentation changes described in the first changelog
+    entry below, and take suitable steps to ensure that your installation or
+    code is secure.
+   </para>
+
+   <para>
+    Also, the changes described in the second changelog entry below may
+    cause functions used in index expressions or materialized views to fail
+    during auto-analyze, or when reloading from a dump.  After upgrading,
+    monitor the server logs for such problems, and fix affected functions.
+   </para>
+
+   <para>
+    Also, if you are upgrading from a version earlier than 9.5.10,
     see <xref linkend="release-9-5-10">.
    </para>
   </sect2>
@@ -35,6 +51,64 @@
 
     <listitem>
      <para>
+      Document how to configure installations and applications to guard
+      against search-path-dependent trojan-horse attacks from other users
+      (Noah Misch)
+     </para>
+
+     <para>
+      Using a <varname>search_path</varname> setting that includes any
+      schemas writable by a hostile user enables that user to capture
+      control of queries and then run arbitrary SQL code with the
+      permissions of the attacked user.  While it is possible to write
+      queries that are proof against such hijacking, it is notationally
+      tedious, and it's very easy to overlook holes.  Therefore, we now
+      recommend configurations in which no untrusted schemas appear in
+      one's search path.  Relevant documentation appears in
+      <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+      <xref linkend="libpq-connect"> (for application authors),
+      <xref linkend="extend-extensions-style">  (for extension authors), and
+      <xref linkend="sql-createfunction"> (for authors
+      of <literal>SECURITY DEFINER</literal> functions).
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid use of insecure <varname>search_path</varname> settings
+      in <application>pg_dump</application> and other client programs
+      (Noah Misch, Tom Lane)
+     </para>
+
+     <para>
+      <application>pg_dump</application>,
+      <application>pg_upgrade</application>,
+      <application>vacuumdb</application> and
+      other <productname>PostgreSQL</productname>-provided applications were
+      themselves vulnerable to the type of hijacking described in the previous
+      changelog entry; since these applications are commonly run by
+      superusers, they present particularly attractive targets.  To make them
+      secure whether or not the installation as a whole has been secured,
+      modify them to include only the <structname>pg_catalog</structname>
+      schema in their <varname>search_path</varname> settings.
+      Autovacuum worker processes now do the same, as well.
+     </para>
+
+     <para>
+      In cases where user-provided functions are indirectly executed by
+      these programs &mdash; for example, user-provided functions in index
+      expressions &mdash; the tighter <varname>search_path</varname> may
+      result in errors, which will need to be corrected by adjusting those
+      user-provided functions to not assume anything about what search path
+      they are invoked under.  That has always been good practice, but now
+      it will be necessary for correct behavior.
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
       Fix misbehavior of concurrent-update rechecks with CTE references
       appearing in subplans (Tom Lane)
      </para>
diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml
index 9077ba9a8d9..c8e6eed7898 100644
--- a/doc/src/sgml/release-9.6.sgml
+++ b/doc/src/sgml/release-9.6.sgml
@@ -23,7 +23,23 @@
    </para>
 
    <para>
-    However, if you are upgrading from a version earlier than 9.6.7,
+    However, if you run an installation in which not all users are mutually
+    trusting, or if you maintain an application or extension that is
+    intended for use in arbitrary situations, it is strongly recommended
+    that you read the documentation changes described in the first changelog
+    entry below, and take suitable steps to ensure that your installation or
+    code is secure.
+   </para>
+
+   <para>
+    Also, the changes described in the second changelog entry below may
+    cause functions used in index expressions or materialized views to fail
+    during auto-analyze, or when reloading from a dump.  After upgrading,
+    monitor the server logs for such problems, and fix affected functions.
+   </para>
+
+   <para>
+    Also, if you are upgrading from a version earlier than 9.6.7,
     see <xref linkend="release-9-6-7">.
    </para>
   </sect2>
@@ -35,6 +51,64 @@
 
     <listitem>
      <para>
+      Document how to configure installations and applications to guard
+      against search-path-dependent trojan-horse attacks from other users
+      (Noah Misch)
+     </para>
+
+     <para>
+      Using a <varname>search_path</varname> setting that includes any
+      schemas writable by a hostile user enables that user to capture
+      control of queries and then run arbitrary SQL code with the
+      permissions of the attacked user.  While it is possible to write
+      queries that are proof against such hijacking, it is notationally
+      tedious, and it's very easy to overlook holes.  Therefore, we now
+      recommend configurations in which no untrusted schemas appear in
+      one's search path.  Relevant documentation appears in
+      <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+      <xref linkend="libpq-connect"> (for application authors),
+      <xref linkend="extend-extensions-style">  (for extension authors), and
+      <xref linkend="sql-createfunction"> (for authors
+      of <literal>SECURITY DEFINER</literal> functions).
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid use of insecure <varname>search_path</varname> settings
+      in <application>pg_dump</application> and other client programs
+      (Noah Misch, Tom Lane)
+     </para>
+
+     <para>
+      <application>pg_dump</application>,
+      <application>pg_upgrade</application>,
+      <application>vacuumdb</application> and
+      other <productname>PostgreSQL</productname>-provided applications were
+      themselves vulnerable to the type of hijacking described in the previous
+      changelog entry; since these applications are commonly run by
+      superusers, they present particularly attractive targets.  To make them
+      secure whether or not the installation as a whole has been secured,
+      modify them to include only the <structname>pg_catalog</structname>
+      schema in their <varname>search_path</varname> settings.
+      Autovacuum worker processes now do the same, as well.
+     </para>
+
+     <para>
+      In cases where user-provided functions are indirectly executed by
+      these programs &mdash; for example, user-provided functions in index
+      expressions &mdash; the tighter <varname>search_path</varname> may
+      result in errors, which will need to be corrected by adjusting those
+      user-provided functions to not assume anything about what search path
+      they are invoked under.  That has always been good practice, but now
+      it will be necessary for correct behavior.
+      (CVE-2018-1058)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
       Fix misbehavior of concurrent-update rechecks with CTE references
       appearing in subplans (Tom Lane)
      </para>