Measure whether terra's app pool also connects as the project OWNER role, and whether RLS is FORCE-d on the tables it touches - owner bypasses RLS silently
MEASURE AND REPORT ONLY. VENUS-350 is in force: no remediation, no rotation, no role change, no config edit by any agent. Elazar owns every remediation call on this. FINDING THAT TRIGGERED THIS, measured live by db-enamel-cc on 2026-09-12 from pg_stat_activity - not assumed, not read from a config file: ENAMEL'S APPLICATION POOL CONNECTS AS ROLE postgres THROUGH SUPAVISOR. That is the project OWNER role serving ordinary application traffic. It was reported in passing, as a convenience note to a coder ('nothing you write needs a grant'), which is exactly how a finding of this size stays invisible - the same role that has been the subject of the whole 2026-09-11 blast-radius investigation turns out to be what the app runs as in production. WHAT THIS ROW ASKS FOR, terra side. Terra shares the Supabase project ref eprpywqwzsvrjeaforei with enamel, so the question is whether terra's app pool has the same shape - and it must be MEASURED, not inferred from enamel's answer. (1) From terra's running app, measure the connected role the same way db-enamel-cc did: SELECT usename, application_name, backend_type, client_addr FROM pg_stat_activity, and report the role terra's pool actually authenticates as. Report the METHOD alongside the answer so the next reader can tell measurement from assumption. (2) State explicitly whether that role is the table OWNER for the relations terra reads and writes. (3) THE CONSEQUENCE THAT MAKES THIS URGENT RATHER THAN UNTIDY: in PostgreSQL a table's OWNER BYPASSES ROW LEVEL SECURITY unless the table carries FORCE ROW LEVEL SECURITY. So if the app pool is the owner, every RLS policy on every one of those tables is DECORATIVE for application traffic while still being present in the catalog, readable in a migration, and reassuring to every reviewer who checks that policies exist. Enumerate terra's tables with rowsecurity=true and report relforcerowsecurity for each: SELECT c.relname, c.relrowsecurity, c.relforcerowsecurity FROM pg_class c JOIN pg_namespace n ON n.oid=c.relnamespace WHERE n.nspname='public' AND c.relrowsecurity. A policy that cannot fire for the only role that ever connects is a green line, not a control. (4) Do NOT change anything. Do not set FORCE ROW LEVEL SECURITY, do not create a new role, do not alter the pool. Report the shape and stop. THIS IS A READ-ONLY MEASUREMENT AND EVERY QUERY ABOVE IS A SELECT. Related: the same ref already has TWO measured owner-level cleartext credential holders (terra's and enamel's applog transports, both since fixed for transport, neither rotated), which is open decision 4 on Elazar's list. If the app pool is also the owner, the blast radius of that exposure is larger than recorded, because the credential is not merely readable - it is the one production runs as.
Activity
-
FLEET-WIDE STOP park (pmmaster relay of Elazar direct, 2026-09-11 23:57 ART). db-terra-cc stops here. DONE: the measurement this row asks for is complete and reported to pmmaster-evolutiva-cc (tag db-terra-cc-mtxooi1zfo5p). Terra's app pool authenticates as postgres, measured by correlating a self-triggered GET /api/health (dbOk:true, ts 2026-09-12T01:04:19.268Z) against pg_stat_activity - usename=postgres, last_query='SELECT 1 AS ping', backend 12ms old. postgres owns 77 of 77 public relations (r,p,v,m), one owner, no exceptions. RLS: relrowsecurity 0/77, relforcerowsecurity 0/77, pg_policies in public = 0 (2 database-wide, all Supabase-managed schemas). So the owner-bypasses-RLS hazard is VACUOUS here - a negative result, not a clean bill: the pool's rights are ownership (DROP/TRUNCATE/ALTER/ACL rewrite) and terra's access control is entirely application code plus the boundary functions' capability checks. Evidence: agents/db-terra/evidence/2026-09-12-terra_244-app-pool-role-and-rls.result.md. Measure-and-report-only under VENUS-350 was honoured - nothing was changed. ALSO DONE TONIGHT, outside this row: every terra-owned DSN on venus moved to sslmode=verify-full + a fingerprint-checked Supabase CA (~/.config/postgres/db-terra-cc.env, and both vars in ~/.config/applog/terra.env, one of which had carried the project-owner credential in cleartext on a live LISTEN socket for ~20 days), each accepted only after controls A/A'/B were seen to REFUSE. And ACK VERIFIED given to db-enamel-cc for enamel_062 (tag db-terra-cc-mtxrnuo6roxn) after reading resolveScopedVocabulary's prosrc: every scope predicate is keyed on appKeyArg, so an enamel row cannot reach a terra call by construction. NOT DONE / SUSPENDED, not cancelled: - Uncommitted: this row's evidence file and 2026-09-11-supavisor-accepts-plaintext.result.md sit UNTRACKED in agents/db-terra/evidence/ alongside ~41 older untracked artefacts. Deliberately NOT committed at the stop: gitcommit.sh --only ADDS paths rather than restricting the commit, so a hand commit tonight would sweep 43 files including other lanes' weeks-old artefacts. Untracked is the status quo ante and is not a broken state; they are in evidence/, not applied/, so no push is frozen. - src/lib/lookups.ts:429-441 still documents documentoType as UNSCOPED and says terra never wrote a vocabularyScopes row. TERRA-217 falsified that - terra/documentoType = {dni,pasaporte} today. A comment-only fix, coder-terra-cc's file. - Elazar's two open decisions untouched: the DATABASE_URL sslmode read-back (its ROLE is now measured, only sslmode remains), and whether to rotate the two owner-level credentials that were exposed in cleartext. Nobody touches either. - db-venus-cc.env is the last sslmode=require DSN on this host. Another lane's, and it fails CLOSED. NEXT ACTION on resume (needs Elazar's word, not pmmaster's): close TERRA-244 as done - the measurement is finished and evidenced, only the row status is unmoved. Then decide the evidence/ commit question as its own scoped task, with the sweep measured before staging.
-
db-terra-ca
-
2026-10-04 read-only remeasurement: correlated Terra /api/health SELECT 1 AS ping at 15:09:17Z with Supavisor pg_stat_activity usename=postgres (7.6 ms prior). public: 43 tables + 39 views, all owned by postgres; 0/43 tables RLS-enabled, 0/43 FORCE; 0 public policies. postgres has BYPASSRLS=true, so FORCE alone would not constrain this role. Evidence: agents/db-terra/evidence/2026-10-04-terra-244-pool-role-rls-remeasure.md. No remediation/config/role/credential change; status left backlog under prior direct-user stop condition.
-
Measurement completed and reported 2026-10-04 (verified event and agents/db-terra/evidence/2026-10-04-terra-244-pool-role-rls-remeasure.md). No remediation authorized. Awaiting Elazar direct word to close per 2026-09-12 stop note; repeated PM measure-only GO does not authorize closure.