From: Tom Lane Date: Mon, 7 Aug 2017 15:46:20 +0000 (-0400) Subject: Last-minute updates for release notes. X-Git-Tag: REL_10_BETA3~4 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=a8b37ebe407f1916c5df22452cdbb1d00e2a409d;p=postgresql Last-minute updates for release notes. Security: CVE-2017-7546, CVE-2017-7547, CVE-2017-7548 --- 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) + + + + +