diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
index 0e8ef04ffa..14fafc0e96 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,126 @@
+
+
+ Further restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Noah Misch)
+
+
+
+ The fix for CVE-2017-7486 was incorrect: it allowed a user
+ to see the options in her own user mapping, even if she did not
+ have USAGE permission on the associated foreign server.
+ Such options might include a password that had been provided by the
+ server owner rather than the user herself.
+ Since information_schema.user_mapping_options does not
+ show the options in such cases, pg_user_mappings
+ should not either.
+ (CVE-2017-7547)
+
+
+
+ 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
+ AND (pg_has_role(S.srvowner, 'USAGE')
+ OR has_server_privilege(S.oid, 'USAGE')))
+ 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.
+
+
+
+
+
+
+
+ Disallow empty passwords in all password-based authentication methods
+ (Heikki Linnakangas)
+
+
+
+ libpq ignores empty password specifications, and does
+ not transmit them to the server. So, if a user's password has been
+ set to the empty string, it's impossible to log in with that password
+ via psql or other libpq-based
+ clients. An administrator might therefore believe that setting the
+ password to empty is equivalent to disabling password login.
+ However, with a modified or non-libpq-based client,
+ logging in could be possible, depending on which authentication
+ method is configured. In particular the most common
+ method, md5, accepted empty passwords.
+ Change the server to reject empty passwords in all cases.
+ (CVE-2017-7546)
+
+
+
On Windows, retry process creation if we fail to reserve the address
@@ -410,77 +535,9 @@
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:
+ follow the corrected procedure shown in the changelog entry for
+ CVE-2017-7547, in .
-
-
-
-
- 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.
-
-
-
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 7e34da2c2b..e95efefd66 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,126 @@
+
+
+ Further restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Noah Misch)
+
+
+
+ The fix for CVE-2017-7486 was incorrect: it allowed a user
+ to see the options in her own user mapping, even if she did not
+ have USAGE permission on the associated foreign server.
+ Such options might include a password that had been provided by the
+ server owner rather than the user herself.
+ Since information_schema.user_mapping_options does not
+ show the options in such cases, pg_user_mappings
+ should not either.
+ (CVE-2017-7547)
+
+
+
+ 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
+ AND (pg_has_role(S.srvowner, 'USAGE')
+ OR has_server_privilege(S.oid, 'USAGE')))
+ 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.
+
+
+
+
+
+
+
+ Disallow empty passwords in all password-based authentication methods
+ (Heikki Linnakangas)
+
+
+
+ libpq ignores empty password specifications, and does
+ not transmit them to the server. So, if a user's password has been
+ set to the empty string, it's impossible to log in with that password
+ via psql or other libpq-based
+ clients. An administrator might therefore believe that setting the
+ password to empty is equivalent to disabling password login.
+ However, with a modified or non-libpq-based client,
+ logging in could be possible, depending on which authentication
+ method is configured. In particular the most common
+ method, md5, accepted empty passwords.
+ Change the server to reject empty passwords in all cases.
+ (CVE-2017-7546)
+
+
+
Fix concurrent locking of tuple update chains (Álvaro Herrera)
@@ -497,77 +622,9 @@
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:
+ follow the corrected procedure shown in the changelog entry for
+ CVE-2017-7547, in .
-
-
-
-
- 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.
-
-
-
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 4eb5c050bf..c616c1a514 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -23,7 +23,12 @@
- However, if you are upgrading from a version earlier than 9.4.12,
+ 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.4.12,
see .
@@ -33,6 +38,140 @@
+
+
+ Further restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Noah Misch)
+
+
+
+ The fix for CVE-2017-7486 was incorrect: it allowed a user
+ to see the options in her own user mapping, even if she did not
+ have USAGE permission on the associated foreign server.
+ Such options might include a password that had been provided by the
+ server owner rather than the user herself.
+ Since information_schema.user_mapping_options does not
+ show the options in such cases, pg_user_mappings
+ should not either.
+ (CVE-2017-7547)
+
+
+
+ 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
+ AND (pg_has_role(S.srvowner, 'USAGE')
+ OR has_server_privilege(S.oid, 'USAGE')))
+ 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.
+
+
+
+
+
+
+
+ Disallow empty passwords in all password-based authentication methods
+ (Heikki Linnakangas)
+
+
+
+ libpq ignores empty password specifications, and does
+ not transmit them to the server. So, if a user's password has been
+ set to the empty string, it's impossible to log in with that password
+ via psql or other libpq-based
+ clients. An administrator might therefore believe that setting the
+ password to empty is equivalent to disabling password login.
+ However, with a modified or non-libpq-based client,
+ logging in could be possible, depending on which authentication
+ method is configured. In particular the most common
+ method, md5, accepted empty passwords.
+ Change the server to reject empty passwords in all cases.
+ (CVE-2017-7546)
+
+
+
+
+
+ Make lo_put() check for UPDATE privilege on
+ the target large object (Tom Lane, Michael Paquier)
+
+
+
+ lo_put() should surely require the same permissions
+ as lowrite(), but the check was missing, allowing any
+ user to change the data in a large object.
+ (CVE-2017-7548)
+
+
+
Fix concurrent locking of tuple update chains (Álvaro Herrera)
@@ -601,77 +740,9 @@ Branch: REL9_4_STABLE [23a2b818f] 2017-08-05 14:56:40 -0700
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:
+ follow the corrected procedure shown in the changelog entry for
+ CVE-2017-7547, in .
-
-
-
-
- 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.
-
-
-
diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml
index aba254e72e..ceece4b8a5 100644
--- a/doc/src/sgml/release-9.5.sgml
+++ b/doc/src/sgml/release-9.5.sgml
@@ -23,7 +23,12 @@
- However, if you are upgrading from a version earlier than 9.5.7,
+ 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.5.7,
see .
@@ -33,6 +38,140 @@
+
+
+ Further restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Noah Misch)
+
+
+
+ The fix for CVE-2017-7486 was incorrect: it allowed a user
+ to see the options in her own user mapping, even if she did not
+ have USAGE permission on the associated foreign server.
+ Such options might include a password that had been provided by the
+ server owner rather than the user herself.
+ Since information_schema.user_mapping_options does not
+ show the options in such cases, pg_user_mappings
+ should not either.
+ (CVE-2017-7547)
+
+
+
+ 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
+ AND (pg_has_role(S.srvowner, 'USAGE')
+ OR has_server_privilege(S.oid, 'USAGE')))
+ 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.
+
+
+
+
+
+
+
+ Disallow empty passwords in all password-based authentication methods
+ (Heikki Linnakangas)
+
+
+
+ libpq ignores empty password specifications, and does
+ not transmit them to the server. So, if a user's password has been
+ set to the empty string, it's impossible to log in with that password
+ via psql or other libpq-based
+ clients. An administrator might therefore believe that setting the
+ password to empty is equivalent to disabling password login.
+ However, with a modified or non-libpq-based client,
+ logging in could be possible, depending on which authentication
+ method is configured. In particular the most common
+ method, md5, accepted empty passwords.
+ Change the server to reject empty passwords in all cases.
+ (CVE-2017-7546)
+
+
+
+
+
+ Make lo_put() check for UPDATE privilege on
+ the target large object (Tom Lane, Michael Paquier)
+
+
+
+ lo_put() should surely require the same permissions
+ as lowrite(), but the check was missing, allowing any
+ user to change the data in a large object.
+ (CVE-2017-7548)
+
+
+
Correct the documentation about the process for upgrading standby
@@ -635,77 +774,9 @@ Branch: REL9_2_STABLE [1188b9b2c] 2017-08-02 15:07:21 -0400
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:
+ follow the corrected procedure shown in the changelog entry for
+ CVE-2017-7547, in .
-
-
-
-
- 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.
-
-
-
diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml
index 3a0a10cbbe..078ac87841 100644
--- a/doc/src/sgml/release-9.6.sgml
+++ b/doc/src/sgml/release-9.6.sgml
@@ -23,7 +23,12 @@
- However, if you are upgrading from a version earlier than 9.6.3,
+ 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.6.3,
see .
@@ -35,6 +40,165 @@
+
+ Further restrict visibility
+ of pg_user_mappings.umoptions, to
+ protect passwords stored as user mapping options
+ (Noah Misch)
+
+
+
+ The fix for CVE-2017-7486 was incorrect: it allowed a user
+ to see the options in her own user mapping, even if she did not
+ have USAGE permission on the associated foreign server.
+ Such options might include a password that had been provided by the
+ server owner rather than the user herself.
+ Since information_schema.user_mapping_options does not
+ show the options in such cases, pg_user_mappings
+ should not either.
+ (CVE-2017-7547)
+
+
+
+ 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
+ AND (pg_has_role(S.srvowner, 'USAGE')
+ OR has_server_privilege(S.oid, 'USAGE')))
+ 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.
+
+
+
+
+
+
+
+
+ Disallow empty passwords in all password-based authentication methods
+ (Heikki Linnakangas)
+
+
+
+ libpq ignores empty password specifications, and does
+ not transmit them to the server. So, if a user's password has been
+ set to the empty string, it's impossible to log in with that password
+ via psql or other libpq-based
+ clients. An administrator might therefore believe that setting the
+ password to empty is equivalent to disabling password login.
+ However, with a modified or non-libpq-based client,
+ logging in could be possible, depending on which authentication
+ method is configured. In particular the most common
+ method, md5, accepted empty passwords.
+ Change the server to reject empty passwords in all cases.
+ (CVE-2017-7546)
+
+
+
+
+
+
+ Make lo_put() check for UPDATE privilege on
+ the target large object (Tom Lane, Michael Paquier)
+
+
+
+ lo_put() should surely require the same permissions
+ as lowrite(), but the check was missing, allowing any
+ user to change the data in a large object.
+ (CVE-2017-7548)
+
+
+
+
+