10000 Last-minute updates for release notes. · divag711/postgres@adb0718 · GitHub
[go: up one dir, main page]
Skip to content

Commit adb0718

Browse files
tglsfdctglsfdc
committed
Last-minute updates for release notes.
Security: CVE-2018-1058
1 parent 70396db commit adb0718

File tree

4 files changed

+300
-4
lines changed

4 files changed

+300
-4
lines changed

‎doc/src/sgml/release-9.3.sgml

Lines changed: 75 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,23 @@
2323
</para>
2424

2525
<para>
26-
However, if you are upgrading from a version earlier than 9.3.18,
26+
However, if you run an installation in which not all users are mutually
27+
trusting, or if you maintain an application or extension that is
28+
intended for use in arbitrary situations, it is strongly recommended
29+
that you read the documentation changes described in the first changelog
30+
entry below, and take suitable steps to ensure that your installation or
31+
code is secure.
32+
</para>
33+
34+
<para>
35+
Also, the changes described in the second changelog entry below may
36+
cause functions used in index expressions or materialized views to fail
37+
during auto-analyze, or when reloading from a dump. After upgrading,
38+
monitor the server logs for such problems, and fix affected functions.
39+
</para>
40+
41+
<para>
42+
Also, if you are upgrading from a version earlier than 9.3.18,
2743
see <xref linkend="release-9-3-18">.
2844
</para>
2945
</sect2>
@@ -33,6 +49,64 @@
3349

3450
<itemizedlist>
3551

52+
<listitem>
53+
<para>
54+
Document how to configure installations and applications to guard
55+
against search-path-dependent trojan-horse attacks from other users
56+
(Noah Misch)
57+
</para>
58+
59+
<para>
60+
Using a <varname>search_path</varname> setting that includes any
61+
schemas writable by a hostile user enables that user to capture
62+
control of queries and then run arbitrary SQL code with the
63+
permissions of the attacked user. While it is possible to write
64+
queries that are proof against such hijacking, it is notationally
65+
tedious, and it's very easy to overlook holes. Therefore, we now
66+
recommend configurations in which no untrusted schemas appear in
67+
one's search path. Relevant documentation appears in
68+
<xref linkend="ddl-schemas-patterns"> (for database administrators and users),
69+
<xref linkend="libpq-connect"> (for application authors),
70+
<xref linkend="extend-extensions-style"> (for extension authors), and
71+
<xref linkend="sql-createfunction"> (for authors
72+
of <literal>SECURITY DEFINER</literal> functions).
73+
(CVE-2018-1058)
74+
</para>
75+
</listitem>
76+
77+
<listitem>
78+
<para>
79+
Avoid use of insecure <varname>search_path</varname> settings
80+
in <application>pg_dump</application> and other client programs
81+
(Noah Misch, Tom Lane)
82+
</para>
83+
84+
<para>
85+
<application>pg_dump</application>,
86+
<application>pg_upgrade</application>,
87+
<application>vacuumdb</application> and
88+
other <productname>PostgreSQL</productname>-provided applications were
89+
themselves vulnerable to the type of hijacking described in the previous
90+
changelog entry; since these applications are commonly run by
91+
superusers, they present particularly attractive targets. To make them
92+
secure whether or not the installation as a whole has been secured,
93+
modify them to include only the <structname>pg_catalog</structname>
94+
schema in their <varname>search_path</varname> settings.
95+
Autovacuum worker processes now do the same, as well.
96+
</para>
97+
98+
<para>
99+
In cases where user-provided functions are indirectly executed by
100+
these programs &mdash; for example, user-provided functions in index
101+
expressions &mdash; the tighter <varname>search_path</varname> may
102+
result in errors, which will need to be corrected by adjusting those
103+
user-provided functions to not assume anything about what search path
104+
they are invoked under. That has always been good practice, but now
105+
it will be necessary for correct behavior.
106+
(CVE-2018-1058)
107+
</para>
108+
</listitem>
109+
36110
<listitem>
37111
<para>
38112
Fix misbehavior of concurrent-update rechecks with CTE references

‎doc/src/sgml/release-9.4.sgml

Lines changed: 75 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,23 @@
2323
</para>
2424

2525
<para>
26-
However, if you are upgrading from a version earlier than 9.4.13,
26+
However, if you run an installation in which not all users are mutually
27+
trusting, or if you maintain an application or extension that is
28+
intended for use in arbitrary situations, it is strongly recommended
29+
that you read the documentation changes described in the first changelog
30+
entry below, and take suitable steps to ensure that your installation or
31+
code is secure.
32+
</para>
33+
34+
<para>
35+
Also, the changes described in the second changelog entry below may
36+
cause functions used in index expressions or materialized views to fail
37+
during auto-analyze, or when reloading from a dump. After upgrading,
38+
monitor the server logs for such problems, and fix affected functions.
39+
</para>
40+
41+
<para>
42+
Also, if you are upgrading from a version earlier than 9.4.13,
2743
see <xref linkend="release-9-4-13">.
2844
</para>
2945
</sect2>
@@ -33,6 +49,64 @@
3349

3450
<itemizedlist>
3551

52+
<listitem>
53+
<para>
54+
Document how to configure installations and applications to guard
55+
against search-path-dependent trojan-horse attacks from other users
56+
(Noah Misch)
57+
</para>
58+
59+
<para>
60+
Using a <varname>search_path</varname> setting that includes any
61+
schemas writable by a hostile user enables that user to capture
62+
control of queries and then run arbitrary SQL code with the
63+
permissions of the attacked user. While it is possible to write
64+
queries that are proof against such hijacking, it is notationally
65+
tedious, and it's very easy to overlook holes. Therefore, we now
66+
recommend configurations in which no untrusted schemas appear in
67+
one's search path. Relevant documentation appears in
68+
<xref linkend="ddl-schemas-patterns"> (for database administrators and users),
69+
<xref linkend="libpq-connect"> (for application authors),
70+
<xref linkend="extend-extensions-style"> (for extension authors), and
71+
<xref linkend="sql-createfunction"> (for authors
72+
of <literal>SECURITY DEFINER</literal> functions).
73+
(CVE-2018-1058)
74+
</para>
75+
</listitem>
76+
77+
<listitem>
78+
<para>
79+
Avoid use of insecure <varname>search_path</varname> settings
80+
in <application>pg_dump</application> and other client programs
81+
(Noah Misch, Tom Lane)
82+
</para>
83+
84+
<para>
85+
<application>pg_dump</application>,
86+
<application>pg_upgrade</application>,
87+
<application>vacuumdb</application> and
88+
other <productname>PostgreSQL</productname>-provided applications were
89+
themselves vulnerable to the type of hijacking described in the previous
90+
changelog entry; since these applications are commonly run by
91+
superusers, they present particularly attractive targets. To make them
92+
secure whether or not the installation as a whole has been secured,
93+
modify them to include only the <structname>pg_catalog</structname>
94+
schema in their <varname>search_path</varname> settings.
95+
Autovacuum worker processes now do the same, as well.
96+
</para>
97+
98+
<para>
99+
In cases where user-provided functions are indirectly executed by
100+
these programs &mdash; for example, user-provided functions in index
101+
expressions &mdash; the tighter <varname>search_path</varname> may
102+
result in errors, which will need to be corrected by adjusting those
103+
user-provided functions to not assume anything about what search path
104+
they are invoked under. That has always been good practice, but now
105+
it will be necessary for correct behavior.
106+
(CVE-2018-1058)
107+
</para>
108+
</listitem>
109+
36110
<listitem>
37111
<para>
38112
Fix misbehavior of concurrent-update rechecks with CTE references

‎doc/src/sgml/release-9.5.sgml

Lines changed: 75 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,23 @@
2323
</para>
2424

2525
<para>
26-
However, if you are upgrading from a version earlier than 9.5.10,
26+
However, if you run an installation in which not all users are mutually
27+
trusting, or if you maintain an application or extension that is
28+
intended for use in arbitrary situations, it is strongly recommended
29+
that you read the documentation changes described in the first changelog
30+
entry below, and take suitable steps to ensure that your installation or
31+
code is secure.
32+
</para>
33+
34+
<para>
35+
Also, the changes described in the second changelog entry below may
36+
cause functions used in index expressions or materialized views to fail
37+
during auto-analyze, or when reloading from a dump. After upgrading,
38+
monitor the server logs for such problems, and fix affected functions.
39+
</para>
40+
41+
<para>
42+
Also, if you are upgrading from a version earlier than 9.5.10,
2743
see <xref linkend="release-9-5-10">.
2844
</para>
2945
</sect2>
@@ -33,6 +49,64 @@
3349

3450
<itemizedlist>
3551

52+
<listitem>
53+
<para>
54+
Document how to configure installations and applications to guard
55+
against search-path-dependent trojan-horse attacks from other users
56+
(Noah Misch)
57+
</para>
58+
59+
<para>
60+
Using a <varname>search_path</varname> setting that includes any
61+
schemas writable by a hostile user enables that user to capture
62+
control of queries and then run arbitrary SQL code with the
63+
permissions of the attacked user. While it is possible to write
64+
queries that are proof against such hijacking, it is notationally
65+
tedious, and it's very easy to overlook holes. Therefore, we now
66+
recommend configurations in which no untrusted schemas appear in
67+
one's search path. Relevant documentation appears in
68+
<xref linkend="ddl-schemas-patterns"> (for database administrators and users),
69+
<xref linkend="libpq-connect"> (for application authors),
70+
<xref linkend="extend-extensions-style"> (for extension authors), and
71+
<xref linkend="sql-createfunction"> (for authors
72+
of <literal>SECURITY DEFINER</literal> functions).
73+
(CVE-2018-1058)
74+
</para>
75+
</listitem>
76+
77+
<listitem>
78+
<para>
79+
Avoid use of insecure <varname>search_path</varname> settings
80+
in <application>pg_dump</application> and other client programs
81+
(Noah Misch, Tom Lane)
82+
</para>
83+
84+
<para>
85+
<application>pg_dump</application>,
86+
<application>pg_upgrade</application>,
87+
<application>vacuumdb</application> and
88+
other <productname>PostgreSQL</productname>-provided applications were
89+
themselves vulnerable to the type of hijacking described in the previous
90+
changelog entry; since these applications are commonly run by
91+
superusers, they present particularly attractive targets. To make them
92+
secure whether or not the installation as a whole has been secured,
93+
modify them to include only the <structname>pg_catalog</structname>
94+
schema in their <varname>search_path</varname> settings.
95+
Autovacuum worker processes now do the same, as well.
96+
</para>
97+
98+
<para>
99+
In cases where user-provided functions are indirectly executed by
100+
these programs &mdash; for example, user-provided functions in ind F438 ex
101+
expressions &mdash; the tighter <varname>search_path</varname> may
102+
result in errors, which will need to be corrected by adjusting those
103+
user-provided functions to not assume anything about what search path
104+
they are invoked under. That has always been good practice, but now
105+
it will be necessary for correct behavior.
106+
(CVE-2018-1058)
107+
</para>
108+
</listitem>
109+
36110
<listitem>
37111
<para>
38112
Fix misbehavior of concurrent-update rechecks with CTE references

‎doc/src/sgml/release-9.6.sgml

Lines changed: 75 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,23 @@
2323
</para>
2424

2525
<para>
26-
However, if you are upgrading from a version earlier than 9.6.7,
26+
However, if you run an installation in which not all users are mutually
27+
trusting, or if you maintain an application or extension that is
28+
intended for use in arbitrary situations, it is strongly recommended
29+
that you read the documentation changes described in the first changelog
30+
entry below, and take suitable steps to ensure that your installation or
31+
code is secure.
32+
</para>
33+
34+
<para>
35+
Also, the changes described in the second changelog entry below may
36+
cause functions used in index expressions or materialized views to fail
37+
during auto-analyze, or when reloading from a dump. After upgrading,
38+
monitor the server logs for such problems, and fix affected functions.
39+
</para>
40+
41+
<para>
42+
Also, if you are upgrading from a version earlier than 9.6.7,
2743
see <xref linkend="release-9-6-7">.
2844
</para>
2945
</sect2>
@@ -33,6 +49,64 @@
3349

3450
<itemizedlist>
3551

52+
<listitem>
53+
<para>
54+
Document how to configure installations and applications to guard
55+
against search-path-dependent trojan-horse attacks from other users
56+
(Noah Misch)
57+
</para>
58+
59+
<para>
60+
Using a <varname>search_path</varname> setting that includes any
61+
schemas writable by a hostile user enables that user to capture
62+
control of queries and then run arbitrary SQL code with the
63+
permissions of the attacked user. While it is possible to write
64+
queries that are proof against such hijacking, it is notationally
65+
tedious, and it's very easy to overlook holes. Therefore, we now
66+
recommend configurations in which no untrusted schemas appear in
67+
one's search path. Relevant documentation appears in
68+
<xref linkend="ddl-schemas-patterns"> (for database administrators and users),
69+
<xref linkend="libpq-connect"> (for application authors),
70+
<xref linkend="extend-extensions-style"> (for extension authors), and
71+
<xref linkend="sql-createfunction"> (for authors
72+
of <literal>SECURITY DEFINER</literal> functions).
73+
(CVE-2018-1058)
74+
</para>
75+
</listitem>
76+
77+
<listitem>
78+
<para>
79+
Avoid use of insecure <varname>search_path</varname> settings
80+
in <application>pg_dump</application> and other client programs
81+
(Noah Misch, Tom Lane)
82+
</para>
83+
84+
<para>
85+
<application>pg_dump</application>,
86+
<application>pg_upgrade</application>,
87+
<application>vacuumdb</application> and
88+
other <productname>PostgreSQL</productname>-provided applications were
89+
themselves vulnerable to the type of hijacking described in the previous
90+
changelog entry; since these applications are commonly run by
91+
superusers, they present particularly attractive targets. To make them
92+
secure whether or not the installation as a whole has been secured,
93+
modify them to include only the <structname>pg_catalog</structname>
94+
schema in their <varname>search_path</varname> settings.
95+
Autovacuum worker processes now do the same, as well.
96+
</para>
97+
98+
<para>
99+
In cases where user-provided functions are indirectly executed by
100+
these programs &mdash; for example, user-provided functions in index
101+
expressions &mdash; the tighter <varname>search_path</varname> may
102+
result in errors, which will need to be corrected by adjusting those
103+
user-provided functions to not assume anything about what search path
104+
they are invoked under. That has always been good practice, but now
105+
it will be necessary for correct behavior.
106+
(CVE-2018-1058)
107+
</para>
108+
</listitem>
109+
36110
<listitem>
37111
<para>
38112
Fix misbehavior of concurrent-update rechecks with CTE references

0 commit comments

Comments
 (0)
0