PostgreSQL 9.6.4 makes password rejection a server rule
The August security update rejects empty passwords at the server, further restricts foreign-server credential visibility, and adds the missing large-object write permission check.
A failed login through one client does not prove that an account cannot authenticate. PostgreSQL's August 10 security update fixes a case where libpq refused to send an empty password, but the server could accept one from a different client. An administrator could mistake a property of the usual client library for an account restriction enforced by the database.
PostgreSQL 9.6.4 and the corresponding supported-branch updates reject empty passwords in password-based authentication. The release also closes another exposure of foreign-server mapping passwords and adds a missing privilege check to large-object writes. Each correction moves an intended restriction into the code path that must enforce it for every relevant caller.
I prefer security rules that remain true when the client changes. PostgreSQL's broad client ecosystem is useful, but a restriction inferred from one driver's behavior is too weak a basis for database authorization. The empty-password issue demonstrates the difference with a small, concrete example.
Empty did not reliably mean disabled
The 9.6.4 release notes at the release tag explain CVE-2017-7546. libpq ignores empty password specifications and does not transmit them to the server. Consequently, a user whose password is an empty string cannot use that password to log in through psql or other libpq-based clients.
A modified client or a client implemented without libpq can behave differently. The server's configured authentication method then determines what happens. In particular, the notes identify md5, the most common method, as one that accepted empty passwords. An account could therefore remain accessible even though testing it through a familiar client suggested otherwise.
The correction makes the server reject empty passwords in all password-based authentication cases. This is a change to the enforcement point. A client no longer needs to reproduce libpq's refusal for the restriction to hold. The announcement also states that the server rejects setting empty passwords on accounts.
This explains why the vulnerability concerns more than an unusual password choice. A client-side refusal had acquired an administrative interpretation, disabling password login, that the server did not consistently implement. The fix resolves the mismatch at the component that accepts or rejects authentication.
It is also a reminder to interpret a connection failure narrowly. The failure establishes that a particular attempt failed under its actual configuration. Without the server rule, it did not establish that every client sending different protocol messages would fail for the same account.
This affects the meaning of an administrative action as well as the outcome of a login attempt. Consistent rejection lets account policy survive a change of driver.
A mapping can contain a credential the mapped user did not supply
CVE-2017-7547 revises the May fix for pg_user_mappings.umoptions. The earlier change still let a user see options in their own mapping without requiring USAGE on the associated foreign server. Those options can contain a password supplied by the server owner, so the fact that the mapping names the user does not settle who should be allowed to inspect it.
The corrected view checks the mapped user's relationship to the foreign server before exposing the options. Its predicate includes server-owner role usage or USAGE on the foreign server, alongside the separately defined cases for public mappings and superusers. The release notes explicitly compare the intended visibility with information_schema.user_mapping_options.
The important distinction is between identifying the user for whom a mapping exists and authorizing that user to inspect its secret options. A server administrator may have supplied those options for controlled access. Showing them solely because the mapping refers to the current user grants an additional capability that the server's usage policy did not grant.
I find this correction particularly relevant to foreign-data access because credentials and database privileges meet in the mapping. The local database is responsible for controlling inspection of information that may authenticate elsewhere. That responsibility remains even when the mapping appears to belong naturally to the user it names.
Existing database views require an explicit replacement
The new view definition takes effect automatically for newly initialized clusters. Existing databases retain their stored view definitions until an administrator changes them. The announcement therefore requires extra steps after upgrading for installations affected by the mapping disclosure.
The release-tag procedure temporarily enables allow_system_table_mods, restarts the server, and replaces the view as a superuser in each database. It sets search_path to pg_catalog before issuing the replacement. This is a cluster-wide catalogue maintenance task even if an installation's application normally uses only one database.
The procedure includes template0 and template1. Without those changes, a database created later can inherit the vulnerable definition. Since template0 normally refuses connections, it must temporarily accept them for the repair and then return to its previous connection restriction. PostgreSQL 9.5 and later provide ALTER DATABASE ... ALLOW_CONNECTIONS for this part of the process.
After replacing the definitions, the release notes say to remove the temporary system-table modification setting and restart again. Binary replacement alone cannot express completion of this fix because the vulnerable object is a view definition already present in database state. The distinction is explicit in both the announcement and the tagged instructions.
Large-object writes need the same permission on every interface
CVE-2017-7548 concerns lo_put(). It should require the same permissions as lowrite(), but lacked the check. Any user could consequently change a large object's data through that function. The fix checks UPDATE privilege on the target large object.
The defect illustrates a different way an intended boundary can fail. Having a checked write interface does not protect an object when another interface performs the same kind of modification without checking. Authorization has to accompany the operation regardless of which supported entry point invokes it.
The release includes more than 50 other fixes, including corrections to concurrent tuple-chain locking and standby promotion. For the security changes, the announcement urges affected users to update promptly. Existing 9.6 installations need no dump and reload for the binary upgrade, while the mapping-view replacement remains required database-level work, including the templates used for future databases.