## Summary The static-masking and replica-masking code builds dynamic SQL that names a column using Rust's `{:?}` (Debug) formatter to "quote" the identifier. Rust's Debug escaping is **not** PostgreSQL identifier-quoting: it only matches for ordinary names and produces a **different, invalid** identifier for any column whose name contains a double quote (`"`), backslash (`\`), or a control character. As a result, masking any table that has a **masked column with such a name fails with an error**, and the dynamic-masking path (which quotes correctly) diverges from the static/replica paths. This is a **correctness / robustness bug**, not an exploitable security issue. ## Affected code Three sites use `{:?}` for a column identifier: - `src/masking/static_masking.rs` — `table_assignments()` (the `UPDATE ... SET` list): ```rust assignments.push(format!("{:?} = {}", name_data_to_str(&attribute.attname), filter_value)); ``` - `src/masking/static_masking.rs` — `column_assignment()`: ```rust Some(format!("{colname:?} = {masking_filter}")) ``` - `src/masking/replica_masking.rs` — `trigger_new_assignments()` (trigger body): ```rust format!("NEW.{:?} = (SELECT {} FROM (SELECT NEW.* ) AS n);", name_data_to_str(&attribute.attname), filter_value) ``` The dynamic-masking path in `src/masking/mod.rs` does it **correctly**, via `utils::quote_name_data(&att.attname)` -> PostgreSQL's `quote_identifier()`. The three sites above are inconsistent with it. ## Root cause: `{:?}` is not the same as SQL identifier quoting `{:?}` on a Rust `&str` wraps it in `"..."` using **Rust string-literal** escaping, which differs from SQL delimited-identifier quoting: | Column name | Rust `{:?}` emits | SQL-correct (`quote_identifier`) | Match? | |---|---|---|---| | `lastname` | `"lastname"` | `"lastname"` | yes (by coincidence) | | `Email` | `"Email"` | `"Email"` | yes | | `a"b` | `"a\"b"` | `"a""b"` | **no** | | `a\b` | `"a\\b"` | `"a\b"` | **no** | | `a`<LF>`b` | `"a\nb"` | `"a`<LF>`b"` | **no** | For an ordinary name (no `"`, `\`, or control chars) the two happen to coincide, which is why existing tests pass. For a name containing those characters, `{:?}` emits an identifier that does **not** equal the real column. ## Impact 1. **Feature breakage (primary).** Any table containing a **masked** column whose name has a `"`, `\`, or control char cannot be statically masked or replica-masked: - `anon.anonymize_table` / `anon.anonymize_column` build an `UPDATE ... SET "wrong" = ...` that references a non-existent identifier -> `column "..." does not exist` -> the call errors and rolls back. - `anon.refresh_replica_trigger_for_table` builds a trigger body that fails to compile for the same reason. 2. **Whole-run abort.** `anon.anonymize_database()` masks all labeled tables in one statement, so a single such column anywhere aborts the entire run (no tables masked that run). The failure is **loud** (an error), not silent. 3. **Inconsistency.** The static/replica paths behave differently from the dynamic-masking path, which quotes correctly. ## Security assessment (why this is filed as a bug, not a vulnerability) - **No SQL injection / privilege escalation.** To break out of the statement, a column name would need a `"`; Rust `{:?}` turns it into `\"`, and PostgreSQL tokenizes that inside a delimited identifier as *literal backslash + closing quote*. The emitted identifier (`...\`) no longer matches the real column, so the `SET "...\" = ...` errors **before** any injected content is reached. Verified on PostgreSQL that this tokenization is identical under `standard_conforming_strings = on` and `off` (that GUC affects single-quoted string literals, not double-quoted identifiers). - **No silent data exposure.** The failure mode is an error + rollback, not a silent skip that would leave cleartext. - A low-privilege user could weaponize (2) to make a shared `anonymize_database()` run error out (an availability nuisance), but it is noisy and self-evident; there is no demonstrated confidentiality/integrity impact.