CockroachDB limits statement details to administrators

A statement fingerprint can hide literal values while still disclosing which tables an application uses. CockroachDB's February 12 advisory A-44348 identifies that distinction in its Statements page and HTTP endpoint. Non-admin users could access statement details covering other users across the cluster, including activity involving objects over which the viewer had no SQL privileges.

The advisory is explicit about the limits of the disclosure. Table contents and the particular values supplied to queries are not accessible through these endpoints. The exposed information still reveals user activity and the existence of databases and tables. That makes the issue an authorization failure even though the diagnostic representation removes an important category of application data.

I accept CockroachDB's consistency costs because their purpose is clear. Diagnostics need a similarly clear access contract. A tool intended to explain application latency should not quietly broaden a user's visibility to unrelated applications sharing the cluster. Aggregation and anonymization are useful transformations, but neither establishes who is entitled to see the result.

Fingerprints retain the shape of application work

The Statements page documentation available at disclosure explains the abstraction. Similar SQL statements form fingerprints after literal strings and numbers are replaced with underscores. That lets the interface group repeated application operations instead of presenting every execution as an unrelated statement.

For example, these illustrative queries differ only in a literal account identifier:

SELECT status FROM customer_accounts WHERE account_id = 17;
SELECT status FROM customer_accounts WHERE account_id = 29;

A fingerprint can remove those identifiers while retaining customer_accounts, status and the selection pattern. That remaining structure is precisely what makes the diagnostic useful for recognizing a class of queries. It is also why the absence of literal values does not remove every confidentiality concern. Object names and access patterns can carry meaning independently of the rows returned.

The same page includes execution counts, retries and latency information. These describe the workload represented by the fingerprint. A viewer can therefore learn that a particular class of operation exists and is active, even without obtaining its parameter values. That is information about another user's work, not merely a list of publicly available SQL syntax.

SQL privileges do not automatically constrain diagnostics

The authorization documentation at the time describes privileges at database and table scope. New users receive the privileges assigned to public and need additional grants for the objects they use. The admin role has privileges across the cluster, and root belongs to it by default.

That model gives ordinary users a narrower intended view than an administrator. A diagnostic endpoint that aggregates statements across users needs its own policy consistent with that distinction. The fact that the viewer cannot SELECT from another table is insufficient if an HTTP response discloses the table's existence and the queries using it anyway.

This is a common administrative design tension. A cluster-wide view is useful for diagnosing overall activity because it crosses application boundaries. The same scope makes it unsuitable as an unrestricted feature for every authenticated user. Supporting a narrower view would require a deliberate definition of which statements the viewer owns or may inspect.

The repair uses an administrative boundary

The 19.2.4 release notes state that the Statements details page and /_status/statements endpoint now require a SQL admin user. Its release date is February 11. The following day's advisory names corresponding fixes in 19.1.8 and 2.1.12 as well, and says 19.2.3, 19.1.7 and 2.1.11 remain affected.

An operator can therefore distinguish the repaired interface from a hypothetical per-user diagnostics feature. This repair restricts the existing cluster-wide information to administrators. It does not claim that ordinary users now receive a filtered version containing only their own work. That scope matters when explaining a page that stops being available to a non-admin after updating.

I regard withholding that broad view as appropriate for the information it contains. Granting admin membership merely to restore a diagnostics page would also grant cluster-wide database authority under the documented role model. A request for performance visibility deserves a narrower access discussion than an automatic promotion to administrator.

Mitigation can target the endpoint or access path

The advisory gives alternatives for installations that have not yet updated. A proxy can block the affected URL while preventing direct HTTP access. A firewall can restrict the HTTP port on unprivileged networks. Another option removes non-admin users' password fields so they cannot use the HTTP interface.

Those choices differ in scope. Blocking one URL aims at the diagnostic operation. Restricting the entire listener changes access to other pages too. Removing a password changes an authentication credential and needs to be understood in the context of how the user connects elsewhere. A mitigation description should identify which of those effects is intended.

The proxy option specifically depends on preventing direct access. If a user can bypass the proxy and reach the node's HTTP port, the proxy's URL restriction does not constrain that request. This follows directly from where the policy is applied. A deployment description needs to establish the route through which affected users reach the interface, as well as the rule installed on that route.

For the same reason, removing a browser link is insufficient as an endpoint restriction. The advisory names an HTTP operation in addition to its visible page. A caller able to send that request does not need to navigate through the interface first.

The ALTER USER reference describes password management as an operation requiring privileges on system.users. The advisory specifically supplies a null password as the mitigation. For an existing non-admin user named diagnostic_reader, its form is:

ALTER USER diagnostic_reader WITH PASSWORD NULL;

This is a credential change, not a query filter. A firewall or proxy policy instead changes which requests can reach the handler. Keeping those mechanisms separate lets an operator select the appropriate temporary restriction, while the maintenance update establishes the endpoint's corrected administrative access requirement.