Isolation Is a Property of the Whole Access Path
The central question is now visible across databases, search indexes, and web applications: does hiding a record from the response also prevent it from influencing everything the caller can observe? This final synthesis connects the PostgreSQL timing case, the Elasticsearch/OpenSearch scoring case, Ote's policy extraction, and the m-NGAC enforcement proposal. It turns them into a practical judgment: evaluate isolation from the query surface through physical work, policy state, observable output, and alternate access paths, while keeping measured behavior separate from architectural intent.
The common failure is participation before redaction
A filtered result is a statement about visibility. Isolation is a statement about influence. The two coincide only when protected data cannot affect a computation or state that reaches the caller through any observable channel. If the system first evaluates a query over shared data and only afterward removes unauthorized rows or documents, the result may be correct at the surface while the path remains informative.
The PostgreSQL and Elasticsearch/OpenSearch studies demonstrate this pattern with different mechanisms. In PostgreSQL, a row-level policy removes unauthorized rows, but optimizer-visible predicates and index access can let a user-selected condition run over the shared table first. A hidden match then changes the amount of work needed to apply the policy, and client-observed timing can distinguish a nonexistent match from a matched-but-filtered one. In the search case, document-level security removes private documents from the response, but BM25 scoring uses corpus-wide statistics. A hidden document can change the score of a visible document, so the response carries information about a corpus the caller cannot read.
These are not two versions of the same implementation bug. Timing and scoring have different triggers, state, and prerequisites. PostgreSQL's signal arises from execution cost and intermediate cardinality. Elasticsearch/OpenSearch's signal arises from term statistics and prefix expansion. The common failure is more abstract: private data participates before redaction in a computation whose consequence remains visible.
The difference matters for diagnosis. A review that checks only returned rows will miss both cases. A review that checks only latency will miss the search case. A review that asks whether any hidden state can affect a caller-visible value, duration, score, error, count, or metadata has a better chance of finding the relevant dependency. The observable need not have been designed as a data interface. It becomes one when a caller can choose a query and compare the result of the system's behavior.
Query expressiveness determines how much information that dependency can yield. The PostgreSQL study shows how an equality-based membership signal can become more powerful when range predicates divide an ordered domain and conjunctions connect values across attributes. The DLS study shows how exact-term membership can become prefix membership and then n-gram reconstruction when autocomplete and search-as-you-type indexes are available. In both settings, the interface supplies the questions that turn a small signal into a search process.
That amplification is not automatic. The PostgreSQL result depends on a measurable timing gap, suitable indexes and predicates, enough stability to repeat observations, and a query surface that exposes the needed conditions. The search result depends on visible scores, attacker-controlled insertions in the described construction, analyzer behavior, prefix-index configuration, and sufficiently stable corpus statistics. A narrow application interface or changing workload can break the demonstrated strategy. But those conditions should be tested, not assumed from the fact that a user cannot directly select a private row or document.
The evidence also distinguishes existence leakage from reconstruction. A timing or score difference may reveal that a hidden value exists without revealing the value itself. Rich ranges, prefixes, and conjunctions can increase the information yield. The PostgreSQL authors report full-row reconstruction under their controlled conditions; the search authors report exact indexed n-gram enumeration and approximate text reconstruction, with ambiguity at graph branches and no unique document boundaries. “A side channel exists” and “the hidden record can be recovered” are separate claims with separate prerequisites.
The same discipline applies to defenses. A control can change the physical access path, remove private data from a statistic, restrict the questions available to the caller, or make a surviving signal harder to measure. Those outcomes are not interchangeable. A composite tenant-leading index paired with an optimizer-visible policy expression addresses the studied PostgreSQL dependency by scoping the access path before the attacker-selected attribute is evaluated. The paper reports that the combined changes closed the useful oracle for that policy shape, while either change alone remained vulnerable. The cost is index complexity, possible impact on non-RLS queries, and limited applicability to policies that cannot be expressed as leading-index constraints.
Search mitigations follow the scoring dependency.