PostgreSQL 9.6.3 closes privilege leaks outside query execution

A database can reject a query and still disclose information while preparing it. PostgreSQL's May 11 security update fixes exactly that class of problem in selectivity estimation. Planner functions could invoke user-defined operators on values from protected column statistics before checking table permissions. A user could exploit the operator call to obtain values they had no permission to select.

The release announcement covers PostgreSQL 9.6.3 and updates to the other supported branches. It closes three security issues, including a separate disclosure of foreign-server passwords and a client-library regression that could defeat an environment-based requirement for encrypted connections. The common concern is a security decision made outside the obvious execution of an application's SELECT statement.

I default to PostgreSQL for relational systems, and explicit privilege boundaries are part of that choice. These fixes matter because the boundary has to hold during planning and administrative inspection as well as ordinary row access. A denied query cannot be allowed to reveal its protected inputs through preparation work.

Statistics contain information about protected data

The release notes preserved at the 9.6.3 tag describe CVE-2017-7484 in terms of pg_statistic. Selectivity functions can use most-common values and histogram entries to estimate how many rows satisfy a condition. Some of those functions apply the query's operator to the stored values.

An operator can be user-defined, so invoking it is potentially an invocation of code supplied by a user. If that code sees a protected statistic value, the later refusal to execute the query cannot undo the disclosure. This is why checking permission only at the eventual table access is insufficient for this path through the planner.

The fix falls back to a default estimate when two conditions hold. The operator's implementation function is not certified leak-proof, and the calling user lacks permission to read the column whose statistics would be used. Either a suitable function certification or read permission permits the usual estimation work. The notes say at least one of those criteria is satisfied in most practical cases.

This introduces a deliberate limit on estimation quality for an unauthorized caller. A default estimate has less knowledge of the column's distribution, but the alternative would expose information the caller may not read. The optimizer's access to statistics does not grant every expression it evaluates the same access to those values.

The distinction also gives a concrete meaning to leak-proofness in this context. It is relevant to whether planner evaluation can disclose protected inputs. A function's usefulness in an ordinary authorized query does not by itself answer that question, and the security correction treats the two properties separately.

Foreign-server access did not imply access to every password

CVE-2017-7486 concerns the umoptions column of pg_user_mappings. Before this update, the owner of a foreign server, or a user granted USAGE on that server, could see options for all its user mappings. Those options could include passwords belonging to other users.

Server usage and credential inspection represent different authorities. Permission to use a foreign server should not automatically expose every user's authentication options for that server. The corrected view follows the behavior of information_schema.user_mapping_options, narrowing visibility according to the mapped user, the rules for a PUBLIC mapping, and superuser status.

This fix has an installation detail that makes the security announcement necessary reading even for administrators familiar with minor upgrades. Replacing the binaries changes the definition used by newly initialized databases. It does not by itself replace the view definition already stored in every existing database.

The release-tag instructions therefore include a separate procedure for existing databases. They require a superuser to replace the view in each database, with temporary system-table modification configuration and server restarts. They also explicitly include template0 and template1, because an unchanged template can carry the old definition into databases created later. The operational scope is the cluster's database definitions, not merely its currently active application database.

I consider that separation essential to understanding the update. A package manager can report success while an existing database still retains its old view definition. The announcement explicitly warns that this security fix needs the documented database-level work as well as updated software.

A documented connection requirement stopped being enforced

The libpq issue, CVE-2017-7485, concerns PGREQUIRESSL. Handling of that environment variable was accidentally removed in PostgreSQL 9.3, while its documentation remained. A client configured to require SSL through the variable could consequently connect without the guarantee its operator expected.

The correction restores recognition of the variable. It gives PGREQUIRESSL lower priority than PGSSLMODE so configurations that work with the intervening releases do not unexpectedly change precedence. The announcement encourages using the sslmode connection-string option because PGREQUIRESSL is deprecated. It also states that the 9.2 series is not affected by this particular issue.

The affected component is the client library. Updating a database server does not establish which libpq a separately installed client uses. The security property depends on the code interpreting the connection configuration, so the relevant application and tool installations belong in the scope of the fix.

This defect is particularly awkward because successful connections can conceal it. An application that receives a connection has not thereby demonstrated that the library enforced the requested encryption policy. Here the configuration text and the library's behavior had diverged, and the update restores the documented check.

Replication initialization needs its own repair decision

Beyond the security changes, the release fixes a potentially invalid initial snapshot created for a logical-decoding replication slot. Third-party replication tools could copy incomplete or inconsistent initial data, particularly when the source was busy or another logical slot already existed. Correcting later decoding does not establish that the initial copy was complete.

The release notes advise recreating the replica after updating, or checking its contents against the source, when such a tool should have copied a nonempty initial dataset. That recommendation follows the same practical distinction as the mapping-view correction. Updated executable code and previously created database state require separate reasoning.

For existing 9.6 installations, no dump and restore is required to install 9.6.3. The announcement prioritizes prompt updating for users relying on PGREQUIRESSL or on isolation among foreign-server users. Its database-level instructions and replica guidance define the additional work that a binary upgrade alone cannot complete.