diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
index b2454ad0612..6aee919ffe0 100644
--- a/doc/src/sgml/release-9.2.sgml
+++ b/doc/src/sgml/release-9.2.sgml
@@ -29,7 +29,12 @@
- However, if you are upgrading from a version earlier than 9.2.20,
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+
+
+
+ Also, if you are upgrading from a version earlier than 9.2.20,
see .
@@ -40,6 +45,124 @@
+
+
+ Restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+
+
+
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server USAGE permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ information_schema.user_mapping_options, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for PUBLIC and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+
+
+
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+
+
+
+
+
+ Restart the postmaster after adding allow_system_table_mods
+ = true to postgresql.conf. (In versions
+ supporting ALTER SYSTEM, you can use that to make the
+ configuration change, but you'll still need a restart.)
+
+
+
+
+
+ In each database of the cluster,
+ run the following commands as superuser:
+
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+
+
+
+
+
+
+ Do not forget to include the template0
+ and template1 databases, or the vulnerability will still
+ exist in databases you create later. To fix template0,
+ you'll need to temporarily make it accept connections.
+ In PostgreSQL 9.5 and later, you can use
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+
+ and then after fixing template0, undo that with
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+
+ In prior versions, instead use
+
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+
+
+
+
+
+
+ Finally, remove the allow_system_table_mods configuration
+ setting, and again restart the postmaster.
+
+
+
+
+
+
+
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+
+
+
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from pg_statistic, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+
+
+
Fix possible corruption of init forks of unlogged indexes
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 44c1e2ac69d..6d620ffacc0 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -23,7 +23,12 @@
- However, if you are upgrading from a version earlier than 9.3.16,
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+
+
+
+ Also, if you are upgrading from a version earlier than 9.3.16,
see .
@@ -34,6 +39,142 @@
+
+
+ Restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+
+
+
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server USAGE permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ information_schema.user_mapping_options, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for PUBLIC and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+
+
+
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+
+
+
+
+
+ Restart the postmaster after adding allow_system_table_mods
+ = true to postgresql.conf. (In versions
+ supporting ALTER SYSTEM, you can use that to make the
+ configuration change, but you'll still need a restart.)
+
+
+
+
+
+ In each database of the cluster,
+ run the following commands as superuser:
+
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+
+
+
+
+
+
+ Do not forget to include the template0
+ and template1 databases, or the vulnerability will still
+ exist in databases you create later. To fix template0,
+ you'll need to temporarily make it accept connections.
+ In PostgreSQL 9.5 and later, you can use
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+
+ and then after fixing template0, undo that with
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+
+ In prior versions, instead use
+
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+
+
+
+
+
+
+ Finally, remove the allow_system_table_mods configuration
+ setting, and again restart the postmaster.
+
+
+
+
+
+
+
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+
+
+
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from pg_statistic, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+
+
+
+
+
+ Restore libpq's recognition of
+ the PGREQUIRESSL environment variable (Daniel Gustafsson)
+
+
+
+ Processing of this environment variable was unintentionally dropped
+ in PostgreSQL 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than PGSSLMODE, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+
+
+
Fix possible corruption of init forks of unlogged indexes
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index fe5ccca5365..ae60b809595 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -23,8 +23,13 @@
- However, if you are using third-party replication tools that depend
- on logical decoding, see the first changelog entry below.
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+
+
+
+ Also, if you are using third-party replication tools that depend
+ on logical decoding, see the fourth changelog entry below.
@@ -38,6 +43,142 @@
+
+
+ Restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+
+
+
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server USAGE permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ information_schema.user_mapping_options, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for PUBLIC and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+
+
+
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+
+
+
+
+
+ Restart the postmaster after adding allow_system_table_mods
+ = true to postgresql.conf. (In versions
+ supporting ALTER SYSTEM, you can use that to make the
+ configuration change, but you'll still need a restart.)
+
+
+
+
+
+ In each database of the cluster,
+ run the following commands as superuser:
+
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+
+
+
+
+
+
+ Do not forget to include the template0
+ and template1 databases, or the vulnerability will still
+ exist in databases you create later. To fix template0,
+ you'll need to temporarily make it accept connections.
+ In PostgreSQL 9.5 and later, you can use
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+
+ and then after fixing template0, undo that with
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+
+ In prior versions, instead use
+
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+
+
+
+
+
+
+ Finally, remove the allow_system_table_mods configuration
+ setting, and again restart the postmaster.
+
+
+
+
+
+
+
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+
+
+
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from pg_statistic, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+
+
+
+
+
+ Restore libpq's recognition of
+ the PGREQUIRESSL environment variable (Daniel Gustafsson)
+
+
+
+ Processing of this environment variable was unintentionally dropped
+ in PostgreSQL 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than PGSSLMODE, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+
+
+
Fix possibly-invalid initial snapshot during logical decoding
diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml
index 3610e3037e1..1c2aca06831 100644
--- a/doc/src/sgml/release-9.5.sgml
+++ b/doc/src/sgml/release-9.5.sgml
@@ -23,8 +23,13 @@
- However, if you are using third-party replication tools that depend
- on logical decoding, see the first changelog entry below.
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+
+
+
+ Also, if you are using third-party replication tools that depend
+ on logical decoding, see the fourth changelog entry below.
@@ -38,6 +43,142 @@
+
+
+ Restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+
+
+
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server USAGE permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ information_schema.user_mapping_options, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for PUBLIC and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+
+
+
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+
+
+
+
+
+ Restart the postmaster after adding allow_system_table_mods
+ = true to postgresql.conf. (In versions
+ supporting ALTER SYSTEM, you can use that to make the
+ configuration change, but you'll still need a restart.)
+
+
+
+
+
+ In each database of the cluster,
+ run the following commands as superuser:
+
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+
+
+
+
+
+
+ Do not forget to include the template0
+ and template1 databases, or the vulnerability will still
+ exist in databases you create later. To fix template0,
+ you'll need to temporarily make it accept connections.
+ In PostgreSQL 9.5 and later, you can use
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+
+ and then after fixing template0, undo that with
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+
+ In prior versions, instead use
+
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+
+
+
+
+
+
+ Finally, remove the allow_system_table_mods configuration
+ setting, and again restart the postmaster.
+
+
+
+
+
+
+
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+
+
+
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from pg_statistic, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+
+
+
+
+
+ Restore libpq's recognition of
+ the PGREQUIRESSL environment variable (Daniel Gustafsson)
+
+
+
+ Processing of this environment variable was unintentionally dropped
+ in PostgreSQL 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than PGSSLMODE, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+
+
+
Fix possibly-invalid initial snapshot during logical decoding
diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml
index bacbc29d67a..e8fb97cb7ff 100644
--- a/doc/src/sgml/release-9.6.sgml
+++ b/doc/src/sgml/release-9.6.sgml
@@ -23,8 +23,13 @@
- However, if you are using third-party replication tools that depend
- on logical decoding, see the first changelog entry below.
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+
+
+
+ Also, if you are using third-party replication tools that depend
+ on logical decoding, see the fourth changelog entry below.
@@ -40,6 +45,174 @@
+
+ Restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+
+
+
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server USAGE permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ information_schema.user_mapping_options, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for PUBLIC and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+
+
+
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+
+
+
+
+
+ Restart the postmaster after adding allow_system_table_mods
+ = true to postgresql.conf. (In versions
+ supporting ALTER SYSTEM, you can use that to make the
+ configuration change, but you'll still need a restart.)
+
+
+
+
+
+ In each database of the cluster,
+ run the following commands as superuser:
+
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+
+
+
+
+
+
+ Do not forget to include the template0
+ and template1 databases, or the vulnerability will still
+ exist in databases you create later. To fix template0,
+ you'll need to temporarily make it accept connections.
+ In PostgreSQL 9.5 and later, you can use
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+
+ and then after fixing template0, undo that with
+
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+
+ In prior versions, instead use
+
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+
+
+
+
+
+
+ Finally, remove the allow_system_table_mods configuration
+ setting, and again restart the postmaster.
+
+
+
+
+
+
+
+
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+
+
+
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from pg_statistic, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+
+
+
+
+
+
+ Restore libpq's recognition of
+ the PGREQUIRESSL environment variable (Daniel Gustafsson)
+
+
+
+ Processing of this environment variable was unintentionally dropped
+ in PostgreSQL 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than PGSSLMODE, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+
+
+
+
+