/estadisticas/clinico broken for all users since the role cutover: mars_app_runtime lacks EXECUTE on fdi_tooth_class, called by 3 security_invoker views
/estadisticas/clinico is broken for every user: mars_app_runtime has no EXECUTE on public.fdi_tooth_class(integer), which three security_invoker views call. First seen in prod 2026-09-14 15:22:07Z (appEvents 0168782a, server error "permission denied for function fdi_tooth_class"). This is deterministic, not transient: nobody had opened the page since the cutover. MEASURED 2026-09-14: fdi_tooth_class(integer) is owned by postgres, and its proacl is {postgres=X, service_role=X, evolutiva_agent_ro=X, evolutiva_agent_rw=X}. There is no PUBLIC entry and no mars_app_runtime entry, and has_function_privilege('mars_app_runtime', ..., 'EXECUTE') returns false. The callers are vPiezaClinicalFacts, vPiezaAccidenteFacts and vConductoMeasurements, all security_invoker=true. So the function's EXECUTE is checked as the calling role, and the runtime role's SELECT on the views does not cover the function inside them. WHY THE CUTOVER MISSED IT: every function the runtime role calls DIRECTLY was covered, but nothing checked functions reached THROUGH a security_invoker view. The permission error only fires at execution time. SCOPE CHECK, so this is one grant and not the first of several: pg_depend from every public view and matview to every non-catalog function mars_app_runtime cannot execute returns exactly these 3 rows, all fdi_tooth_class. Denials in appEvents over 14 days: this one, plus 2x drain_email_outbox_if_due and 1x cron_auth_header on 2026-09-10, which are cron/internal. cron_auth_header MUST STAY REVOKED, standing rule. BOUND: pg_depend does not track calls inside plpgsql or SQL function BODIES, so a function reaching fdi_tooth_class through another function's body is not covered by this check. The views are the path this page uses. FIX (DB lane): GRANT EXECUTE ON FUNCTION public.fdi_tooth_class(integer) TO mars_app_runtime; to that role only, NEVER to PUBLIC, because fn_assert_no_public_execute exists to catch exactly that. In the SAME migration, add the grant to the runtime privilege manifest (fn_runtime_privilege_manifest) so fn_assert_runtime_privilege_manifest does not flag it as drift. The function is a pure tooth-number-to-class helper, so granting it exposes no data. ACCEPTANCE: has_function_privilege('mars_app_runtime','public.fdi_tooth_class(integer)','EXECUTE') returns true; SET ROLE mars_app_runtime; SELECT 1 FROM "vPiezaClinicalFacts" LIMIT 1 (and the other two views) succeeds; both privilege asserts pass; /estadisticas/clinico renders with no new permission-denied row. Get the failing result under SET ROLE mars_app_runtime BEFORE granting, so the fix is shown turning a real failure into a pass. This is a permission change, so it needs a DEEP review before apply by a lane other than the author.
Activity
-
ACCEPTANCE REVISED 2026-09-14 by coder-mars-cc (PM seat). Why: db03-mars-ca found that the maintenance postgres connection is not allowed SET LOCAL ROLE mars_app_runtime, so the SET ROLE before/after transcript cannot honestly be produced. Replacing it with checks that test the same thing without a synthetic run. BEFORE, already met: the real production failure, appEvents 0168782a at 2026-09-14 15:22:07Z, 'permission denied for function fdi_tooth_class', raised by mars_app_runtime on the real authenticated app path. That is a stronger before-proof than a synthetic SET ROLE run. Plus has_function_privilege('mars_app_runtime', fdi_tooth_class(integer), 'EXECUTE') = false, read independently by coder-mars-cc and db03-mars-ca. AFTER: (1) the same has_function_privilege read returns true, which is the exact check the executor applies to the calling role of a security_invoker view; (2) fn_assert_no_public_execute and fn_assert_runtime_privilege_manifest both pass; (3) the next REAL /estadisticas/clinico render writes no permission-denied row. Until (3) is seen, the fix is recorded as GRANTED, NOT YET EXERCISED, never as verified. Do NOT create a new login path or role just to run the proof: that would widen access to test a grant.
-
ELAZAR DECISIONS OWED, recorded here so they outlive this session's context (2026-09-14). db03-mars-ca correctly refused to write the migration: mars-commons.md §Agent Code-Edit Authorization lists only coder-mars-cc, coder02-mars-cc and db-mars-cc, and a PM DM is not a grant. So every Codex seat on Mars (coder03-mars-ca, 51 items; db03-mars-ca, 22 items) is analysis-only until the roster file is edited. Three questions for Elazar: (1) add coder03-mars-ca (code + push) and db03-mars-ca (handoff commits only) to the mars-commons roster; coder-mars-cc edits and pushes it on GO. (2) who gates Codex output: coder02-mars-cc declined, and coder-mars-cc recommends itself. (3) lift the production-write hold, at least for this row. FASTEST UNBLOCK for this outage: db-mars-cc is already authorized, so on GO it writes and applies this single grant and coder-mars-cc reviews it. MARS-735 and MARS-736 wait on the same three answers.
-
2026-09-15 Elazar ruling landed in mars-commons.md: db03-mars-ca is a standing-authorized Mars DB agent for narrowly scoped corrective production changes (schema/function/view/role-privilege migrations only, no destructive/broad/credential/platform changes, never pushes). It may author+apply+handoff-commit without a per-change GO after coordinating scope/timing with coder03-mars-ca and getting an independent audit from general-audit-cc. This unblocks MARS-737's fdi_tooth_class grant: db03-mars-ca authors/applies, general-audit-cc reviews, coder03-mars-ca coordinates timing. coder-mars-cc's earlier fast-path offer (db-mars-cc applies, I review) is superseded; review lane is general-audit-cc, not me.
-
MARS-737 migration 165 prepared: exact grant public.fdi_tooth_class(integer) to mars_app_runtime only, with no-PUBLIC/runtime assertions and existing fences. audit-general-cc PASSed corrected design. The ticket's proposed function-manifest row was removed: fn_runtime_privilege_manifest is table-only. Production SQL access is denied to this session, so no apply is claimed.
-
db-mars-cc read-only check 2026-09-19: has_function_privilege('mars_app_runtime','public.fdi_tooth_class(integer)','EXECUTE') = true; proacl = {postgres,service_role,evolutiva_agent_ro,evolutiva_agent_rw,mars_app_runtime=X}, no PUBLIC entry. Grant is live (commit 3c77adb). Not exercised: the /estadisticas/clinico page itself and the three views under the runtime role. Row left inProgress for db03-mars-ca to close.
-
Verified live: fdi_tooth_class(integer) has mars_app_runtime EXECUTE=true. Grant confirmed applied (db-mars-cc, 2026-09-22).