PostgreSQL 11.1 fixes trigger names in database dumps

A database dump represents objects as commands that another database will execute. That transformation creates a security boundary. An object name supplied by an ordinary user must remain an identifier when the dump emits it as SQL. If the generator quotes it incorrectly, stored metadata can become executable syntax under the identity performing the restore.

PostgreSQL 11.1 fixes such an error for transition-table names in generated trigger definitions. The November 8 announcement identifies CVE-2018-16850 in PostgreSQL 10 and 11. A crafted trigger definition could produce superuser SQL execution during pg_upgrade or a dump and restore. The stated prerequisites include CREATE on a non-temporary schema or TRIGGER on a table.

I regard backup and upgrade tooling as part of the database's security model. A tool can read metadata successfully and still serialize it unsafely. For PostgreSQL, whose schema is a substantial part of the application, preserving the meaning of object names matters as much as preserving the rows associated with those objects.

Metadata becomes a privileged input

The 11.1 release notes describe the repair as proper quoting of transition-table names in CREATE TRIGGER ... REFERENCING commands emitted by pg_dump. The original error allowed an unprivileged user to gain privileges during a later maintenance operation. That delay distinguishes the failure from an ordinary statement that immediately escapes its caller's permissions.

The attacker-controlled object can exist before the vulnerable tool processes it. A database may therefore appear to accept ordinary schema changes while retaining input that becomes dangerous only when exported and executed again. The maintenance identity supplies the elevated authority at that later stage. The export process needs to preserve the boundary between the original identifier and the SQL grammar around it.

This is a serialization problem with an authorization consequence. The source database has a structured representation of an object. A textual dump must encode that structure into a language containing both identifiers and commands. Correct quoting tells the parser which category a piece of text belongs to. Losing that distinction can change the meaning of the generated program.

It is tempting to treat schema metadata as more trustworthy than application data because administrators usually inspect it less often. The release demonstrates why that assumption needs to be tied to actual creation privileges. A user who can define a trigger can supply parts of the metadata a privileged tool will later read. The tool cannot assume that every object name originated with its own operator.

The announcement notes that the default public-schema CREATE grant makes the issue exploitable in the default configuration. That is a specific access condition, not a claim that every user on every database has identical privileges. Installation review needs to consider the grants actually present. Restricting those grants and installing corrected tools address different parts of the path.

A backup is also a reconstruction program

Thinking of a dump only as a collection of rows misses the executable instructions required to reconstruct the schema. A restore needs definitions and dependencies, and those definitions can carry names supplied by less privileged identities. The security of reconstruction depends on how the tool translates those names, not merely on whether the source database accepted them.

The same reasoning explains why pg_upgrade appears in the advisory. A maintenance workflow can use schema reconstruction internally without presenting itself to the operator as an export followed by a restore. Its safety still depends on the components that generate and consume those definitions. The outer command's purpose does not remove the inner translation boundary.

My preference is to evaluate these operations by the input they process and the identity that executes the resulting SQL. That makes a delayed failure easier to understand. An ordinary user's metadata and a superuser's maintenance command meet inside the workflow, even though the two people never exchange a SQL file directly.

This also gives the fix a precise operational meaning. Corrected generation prevents the affected names from becoming unintended syntax in newly produced output. That is the behavior the release promises. It does not support an assumption that every pre-existing dump was generated with the corrected quoting or that an older tool becomes safe because its target server was updated.

For an administrator describing a maintenance procedure, the tool version therefore belongs beside the server versions. The source server owns the metadata, the dump program chooses its textual representation, and the restore identity executes it. Recording only the destination version leaves out the component responsible for this defect. That distinction is useful when deciding which existing procedures need updated executables before their next run. It also explains why a successful row-count comparison would not demonstrate the absence of an injection through a schema definition.

Statistics readers lose reset authority

The release notes also remove the ability of pg_read_all_stats to execute pg_stat_statements_reset(). The role is intended to read statistics, so granting it a reset operation was incorrect. For installed extensions retaining the old grant, the documented update is:

ALTER EXTENSION pg_stat_statements UPDATE;

The command applies in each database containing the extension. This makes the permission repair an installed-object change as well as a software change. A database upgraded from an earlier release can retain older extension metadata even when its server binaries are current.

Reading statistics and clearing statistics are different powers. A monitoring identity may need visibility without authority to erase the accumulated observations other users depend on. Keeping the grant aligned with that distinction makes the role useful for inspection without silently giving it a maintenance operation.

The November announcement advises this extension update for PostgreSQL 10 and 11 installations using pg_stat_statements. Its normal minor-update path does not require dump and reload. These instructions identify the narrower follow-up operation required for the stored grant, so an operator can complete the repair without inventing a broader migration.

For the trigger-quoting issue, the affected boundary is the conversion of stored identifiers into executable SQL. For the statistics grant, it is the distinction between observing and changing shared diagnostic state. Both fixes matter to administrative workflows whose visible purpose sounds read-oriented, but whose implementation or permissions can carry authority beyond inspection.