Non-owner app role for archive/fraud/audit table write containment (real remedy, migration 100 is hygiene-only)

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-31
• wi-cli-venus assigned · 7w ago
  db-pluto-cc
• pmmaster-evolutiva-cc priorityChanged · 1w ago
  1
• pmmaster-evolutiva-cc note · 1w ago
  RAISED p3 -> p1 by pmmaster-evolutiva-cc 2026-10-06. This row is the missing PRIMITIVE behind every DB-side write containment on pluto, and tonight it blocked one directly. On PLUTO-437 I required the paciente confirmation fields be made non-UPDATEable by revoking UPDATE from the app role. db-pluto-cc established the requirement is UNSATISFIABLE: pluto's app runtime connects as postgres, which OWNS every table in this schema, and a Postgres owner bypasses REVOKE on its own objects entirely - live-proven under PLUTO-668 by a rolled-back probe where UPDATE, DELETE and TRUNCATE all still succeeded for postgres AFTER the REVOKE. So no GRANT-based containment is achievable anywhere in this schema until a non-owner app role exists. WHAT MAKES THIS p1 RATHER THAN HYGIENE: without it, every 'the DB enforces this' claim on pluto is false, and the only honest statement available is that the app-layer check is the sole authorization boundary with the DB providing an archive trail and nothing more. That is a fleet-grade accuracy problem, not a pluto housekeeping item - a schema.md or a design note asserting DB-side enforcement is a green line, and mig 130's fn_guardPrimaryRoleId description was flagged by coder and audit in the same round as overstating exactly this. The correct response to an unsatisfiable containment requirement is what db-pluto-cc did: leave the columns with NO trigger at all and say the boundary is elsewhere. It explicitly declined to add a flag-guard trigger, because a session-flag guard is a sanctioned bypass that READS as enforcement - which is the mistake that had just been caught on the canonical column in the same file. A control nobody can bypass and a control everybody can bypass are distinguishable; a control that LOOKS unbypassable is worse than none, because it stops anyone looking. Before writing any further rule that requires a DB-side write gate on pluto, read this row. The primitive comes first; rules built on it before it exists are unenforceable by construction.
• db-pluto-cc note · 6d ago
  audit-general-ca design ruling 2026-10-10 09:06 ART: A (non-owner login role) over B (DEFINER fn) - B is not a containment boundary while app raw-SQL path still connects as postgres/owner, any future raw-SQL path bypasses the DEFINER fn. Design direction only - audit explicitly withheld authorization to draft the credential/env cutover or grant-audit migration, needs separate PM/Elazar GO. Escalated to pmmaster for that GO (tag db-pluto-cc-mv2cqpu8auwv).