Avoid leaking system path from pg_available_extensions

First seen: 2026-05-20 01:00:29+00:00 · Messages: 11 · Participants: 5

Latest Update

2026-06-01 · claude-opus-4-6

Monthly Summary: Avoid Leaking System Path from pg_available_extensions (May 2026)

Overview

This thread addresses an information disclosure bug in the pg_available_extensions view's location column, introduced by the recent "Add paths of extensions to pg_available_extensions" feature. The issue was identified, patched, reviewed, and refined to v2 within the month.

The Bug

The extension_control_path GUC documents that an empty string ('') should behave identically to the default value '$system'. However, the pg_available_extensions view inconsistently reports the location:

The root cause: when the GUC is explicitly set to empty string, the code resolves it to the physical system directory for file-searching purposes, then passes that resolved path directly to the view output rather than mapping it back to the $system token.

Security Significance

While not critical (requires SET privileges), the leak violates the design intent of the $system abstraction, which exists to hide server filesystem details. This matters for cloud-managed PostgreSQL services, multi-tenant environments, and compliance scenarios requiring minimal information disclosure.

Patch Evolution

v1: Core Fix

The initial patch ensures that when extension_control_path resolves to the system extension directory (via '$system', empty string, or default), the location column consistently displays $system. Described as straightforward and low-risk.

v2: Function-Scoped Macro

After Jim Jones suggested extracting the "$system" string literal into a named constant, Evan Li posted v2 which uses a function-scoped #define/#undef pattern within get_extension_control_directories(). This avoids repeating the literal three times in one function (the fix added comparison logic that increased usage from once to thrice). The pattern has precedent in pg_resetwal.c.

The core fix logic is unchanged between v1 and v2.

Current Status

The patch (v2) has accumulated multiple reviewer approvals with no outstanding objections. The discussion is effectively concluded, awaiting commit.

History (1 prior analysis)
2026-06-01 · claude-opus-4-6

Incremental Update: Patch Committed

The v2 patch has been pushed to the repository by Andrew Dunslane on 2026-05-30. Evan Li acknowledges the commit.

No new technical discussion, objections, or follow-up issues were raised. This thread is now concluded.