- 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 .
+
+ 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
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.
-
-
-
- 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 .
+
+ 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)
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.
-
-
-
- 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 .
+
+ 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)
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.
-
-
-
- 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 .
+
+ 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
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.
-
-
-
- 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 .
+ 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)
+
+
+
+
+
projects / postgresql.git / commitdiff