GRANT a rol individual con nombre de CUIT: agrupar en movilba_readonlyusergroup

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc
• wi-cli-venus note · 4w ago
  MEDICION EN PROD - db02-mba-l-cc, 2026-09-12, SOLO LECTURA (movilba @ 10.78.42.168, PG 17.6). El item queda EN PIE pero cambia de forma: no es solo agrupar, hay escritura directa concedida y dos roles con superusuario. No transcribo ningun valor de identificacion tributaria; todo va como conteo. 1. CONFIRMADO EL ENCABEZADO: hay 10 roles de Postgres cuyo nombre es un numero de 11 digitos, los 10 con LOGIN, y solo 3 son miembros de movilba_readonlyusergroup. Ninguno de los 10 es miembro de ningun OTRO grupo. 2. HALLAZGO NUEVO Y ES EL QUE CAMBIA LA PRIORIDAD: 3 de esos roles tienen privilegio COMPLETO (arwdDxtm: select, insert, update, delete, truncate, references, trigger) concedido DIRECTO sobre 55 objetos del schema public. Otros 3 tienen solo lectura, sobre 91 objetos. En total 6 de los 10 aparecen en el ACL de 94 objetos. Un item titulado 'agrupar en readonlyusergroup' no describe eso: meter un rol con escritura directa en un grupo de lectura no le saca la escritura - el GRANT directo sobrevive al alta en el grupo. Hay que REVOCAR, no solo agrupar, y revocar es una decision distinta porque puede romper a quien hoy escribe. 3. SEGUNDO HALLAZGO: 2 de los 10 son SUPERUSER. Para esos dos, cualquier esquema de grupos es decorativo - un superusuario atraviesa todo ACL. Si la intencion del item es acotar el acceso, esos dos no se resuelven con pertenencia a un grupo, se resuelven quitando el atributo, que es otra decision y mas grande. 4. EL GRUPO SI ESTA CABLEADO: movilba_readonlyusergroup tiene GRANT sobre 91 objetos de public, y 4 miembros en total (3 de ellos con nombre de 11 digitos). O sea que el destino del item existe y funciona; lo que falta es mover a los otros y sacarles lo directo. 5. DONDE MAS VIVE EL NUMERO, ademas del DDL que el item menciona: 6 entradas en el ACL del schema public (pg_namespace.nspacl) y 3 entradas en privilegios por defecto (pg_default_acl). Un ALTER DEFAULT PRIVILEGES nombrando a una persona es peor que un GRANT suelto: se aplica solo a cada objeto FUTURO, asi que el numero se sigue propagando sin que nadie escriba un script. 6. CONTROL POSITIVO - de acuerdo con lo que pide el item y lo refuerzo: despues de mover a un rol al grupo, el SELECT como ese rol tiene que seguir andando. Y agrego el control NEGATIVO que falta: despues de revocar la escritura directa, un INSERT como ese rol tiene que FALLAR. Sin el negativo, 'ya no escribe' no esta medido. 7. TRAMPA DE MEDICION QUE ME COMI Y QUE AFECTA A CUALQUIERA QUE AUDITE ESTO: information_schema.role_table_grants me dio CERO grants directos para estos roles. Es un cero FALSO - esa vista solo muestra los grants donde el usuario que consulta es el que concedio, el concedido, o miembro de alguno. La fuente que contesta de verdad es pg_class.relacl desestructurada con unnest, que devolvio los 94 objetos. Un permiso NO se audita por information_schema. 8. PEDIDO SOBRE ESTE MISMO ITEM: el cuerpo de la descripcion lleva diez numeros de identificacion tributaria escritos. La regla vigente es que no van en un ticket ni en un archivo trackeado. Recomiendo reemplazarlos por un puntero a una lista fuera del tracker y dejar en la fila solo los conteos. No lo edito yo: cambiar la descripcion de una fila ajena es una escritura de contenido y la decide quien la creo. Nada ejecutado. Este item es DDL de PROD y necesita su GO propio.
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:05 -03 — Status sweep limitation: Current PROD role membership and grants were not censused; no claim about named personal roles or privileges is made. BWI show and recent events were read; status unchanged and no DB write.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc 2026-10-05 15:29 ART - REMEASURED on PROD via pg_class.relacl/aclexplode, SELECT only. information_schema.role_table_grants returns 0, a visibility artifact, NOT evidence. DEV movilba_dev has no CUIT roles. 10 CUIT login roles, 0 active sessions, none with an expiry. Four groups: 1. In the group already: 20384559221, 20394678369, 20421184020; no individual grants. 2. SELECT-only individual: 20049796634, 27308864826, 27372742122, 87 public relations each. All 87 are already covered by movilba_readonlyusergroup (0 not in the group), but the group grants 124, so joining WIDENS their read by 37 relations. They are also named in pg_default_acl (postgres, public, r), which is how every new table re-acquires a CUIT grant. 3. WRITE individual: 20313154204 (16 rels) and 23375370409 (16 rels), arwdDxtm on public; 20366097083 (84 rels, plus USAGE on sequences). All three also have USAGE on schema rutap except 23375370409. 4. Nothing but USAGE on public: 20232157888. docs/migrations: 9 files carry these CUITs in DDL. Proposed fix (needs Elazar, since it changes real people's access): A) group 2 joins movilba_readonlyusergroup (+37 relations visible), their individual grants and the default-ACL entries are revoked; groups 3 and 4 untouched. B) A, plus a new movilba_writeusergroup for group 3, with the same privileges they have today, granted at group level. C) A, plus revoking the writes of group 3 if they should not have them. Who these people are and why 3 can write is his knowledge, not measurable here.
• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08, synthesis for Elazar's decision - no new measurement, distilling db03's 2026-10-05 progress note. WHAT EXISTS: 10 Postgres login roles named by CUIT, 0 active sessions, none expiring. Four groups by current privilege: - 3 already in movilba_readonlyusergroup, no individual grants - untouched by any fix. - 3 SELECT-only individual (87 relations each) - already a SUBSET of what the group grants (124 relations), so moving them in only WIDENS their read by 37 relations; also named in pg_default_acl, which is how every NEW table keeps re-granting them individually. - 2 WRITE roles (16 relations, arwdDxtm) + 1 bigger WRITE role (84 relations + sequence USAGE) - these have real INSERT/UPDATE/DELETE today, not just read. - 1 USAGE-only on schema public, nothing else. WHO CONNECTS AS WHAT: not measurable from the DB - a CUIT role name doesn't say which person/app authenticates as it. That's Elazar's own knowledge. WHAT BREAKS IF RENAMED/REGROUPED: 9 files under docs/migrations/ carry these CUITs literally in DDL (SELECT/GRANT statements referencing the role name) - renaming a role breaks any migration re-run that names the old literal. The pg_default_acl entries for the SELECT-only group are the live propagation mechanism (every new table re-acquires their individual grant) - folding them into the group removes that, which is the point, but is also the part most likely to surprise someone if a new table's expected-visible-to-X assumption depended on it. DECISION OWED: db03's A/B/C (readonly-group-only / readonly-group+new write-group / readonly-group+revoke-the-writes) all preserve current access shape differently - A silently WIDENS 3 roles' read by 37 relations with no equivalent narrowing anywhere; C is the only one that changes anyone's write capability. Whether the 3 write roles should keep writing is a "why does this person/app write" question only Elazar can answer.
• coder03-mba-l-cc note · 1w ago
  coder03 2026-10-08 13:22 ART: option A is withdrawn, not escalated. Joining the three SELECT-only roles to the readonly group silently widens their read by 37 relations with no compensating narrowing, so it is a flawed proposal rather than one side of a choice. What remains is a single question only Elazar can answer, because it is his own history and not measurable from the cluster: why three roles hold direct write. Nothing is implemented until that is answered.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 ART, cross-link: the same CUIT-named PROD roles this item is about hold SELECT on the eight views in the MOVILBA-667 batch-drop decision. Measured by aclexplode on relacl: 20049796634, 27308864826 and 27372742122 hold SELECT on seven of the eight, and 20366097083 additionally on v_ui_users; alongside them movilba_readonlyusergroup, penql, audit_ro, nossesmacchia and svc_nextjs, which is on all eight. Census: docs/reference/movilba-667-ocho-vistas-relacl-y-dependencias.md e9ce78b7. The point that belongs here: no instrument on these bases currently attributes a read to one of those roles - pg_stat_user_tables counts since the last reset with no per-role attribution and pg_stat_activity is a snapshot - so whether any of them is a live reader is UNMEASURED, not absent, and a DROP VIEW discards their grants irrecoverably while a REVOKE is reversible. researcher-mba-l-cc is measuring which instrument, if any, would show it. No change to this item's scope and no write.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 21:51 ART, the instrument half, measured on both bases, SELECT-only. This closes the question of whether a read by one of the CUIT-named roles could be SEEN: it cannot, by any instrument present. log_statement is 'ddl' in PROD and 'none' in DEV, and log_min_duration_statement is -1 in both, so no SELECT reaches the log by statement class or by duration. No pg_extension row matching '%stat_statements%' or '%audit%' in either base - no query-text history, no pgaudit. pg_stat_user_tables has no row for a plain view at all, with the instrument seen reporting in the same query (public.vehiculos at 954,470 idx_scan in PROD and 2,276,342 in DEV), and stats_reset is NULL in both, so the counter window has no nameable start - an open-ended window with no per-role attribution is not a usable instrument. Reads arriving THROUGH a view do move its BASE table's counters, which is why those numbers are not zero and why they cannot separate 'nobody reads v_users' from 'a CUIT role reads it nightly'. CONSEQUENCE for this item's framing: the residual risk on those roles is not 'unknown', it is UNKNOWABLE with current instruments, which is a different sentence - the remedy would be turning an instrument ON (log_statement='all', or installing pg_stat_statements) and that is a change to PROD configuration, not a measurement, so it is Elazar's call and I am not proposing it here. researcher-mba-l-cc holds the capability doc; the grants themselves are in docs/reference/movilba-667-ocho-vistas-relacl-y-dependencias.md e9ce78b7.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 22:02 ART - THE CUIT HALF, per-role, measured on PROD today, SELECT-only. This is what 230 was owed; my 00:51 note was the instrument half and is superseded on that point by the citation in the following note. INSTRUMENT. tools/verification/movilba-230-roles-cuit-censo.sql, written as the repeatable form of this measurement. It names NO CUIT literally - everything comes from the predicate rolname ~ '^[0-9]{11}$' and the read-only exemplar is picked by privilege SHAPE (most SELECT, zero INSERT), so the per-role list stays here, where the description already names the ten, and not in a tracked file. The file was swept into coder03's 22:01 park stash seconds after creation and comes back with the park; one defect in its block G is pending re-application and re-run before any sha is cited, and no sha is cited here. TWO OF THE TEN ARE SUPERUSER, and this is the fact that changes the item's shape. db02 measured it on 2026-09-12 (its point 3) and I am re-confirming it, not reporting it as new: 20313154204 and 20366097083 have rolsuper, plus CREATEROLE and CREATEDB. No role has BYPASSRLS or REPLICATION. For those two a group change or a REVOKE has NO effect on what they can do, because a superuser traverses every ACL - their real decision is NOSUPERUSER, which is a bigger and separate call. CONSEQUENCE: option C, 'revoke the writes of group 3', is a no-op for two of its three roles. The only role whose write a REVOKE actually removes is 23375370409, which is not a superuser and holds INSERT/UPDATE/DELETE/TRUNCATE on 16 tables by direct grant - measured by has_table_privilege, which says it can INSERT into public.vehiculos. THE FOUR GROUPS, with the relkind breakdown that the earlier figures lacked. The breakdown is asserted to exhaust each role's SELECT total, and the assert was seen to print. 1. In the group already, zero direct grants: 20384559221, 20394678369, 20421184020. Nothing to do. The group's fourth member is not a CUIT role, it is a named person role (an @buenosaires.gob.ar address), so the group already mixes both shapes. 2. SELECT-only, 87 objects each = 38 tables + 36 views + 13 matviews, zero unclassified: 20049796634, 27308864826, 27372742122. These are the only three the item's own remedy reaches. 3. Superuser + direct write: 20313154204 (16 tables, arwdDxt) and 20366097083. The second one's shape was stated imprecisely before and is corrected here: SELECT/UPDATE on 84 objects but INSERT/DELETE/TRUNCATE on only 51, because the 84 = 35 tables + 16 views + 33 sequences and a sequence takes SELECT/UPDATE/USAGE and never INSERT. So its WRITE scope is 51 objects, not 84, and the earlier phrasing '84 rels plus USAGE on sequences' counted the sequences twice. 4. 23375370409: not superuser, 16 tables with full write. See above. 5. 20232157888: ZERO direct privileges on any public relation, and has_table_privilege says it cannot even read public.vehiculos. Its public USAGE comes from PUBLIC, not from a grant of its own - nspacl names no CUIT. So it is not 'USAGE-only', it has nothing, and joining it to the group would not be a regrouping, it would be a NEW grant of 124 relations it does not have today. That is a different decision from the other two and should not ride along silently. THE 37 ARE ALL SEQUENCES, and this corrects the stated basis for withdrawing option A. The group grants SELECT on 124 public relations; a group-2 role has 87; the difference is 37 and the relkind breakdown says every one of the 37 is relkind='S'. Zero tables, zero views, zero matviews. Measured in BOTH directions with the control printing: 0 objects of the role sit outside the group, so the 87 are a strict subset and joining never takes anything away. coder03's withdrawal rested on 'silently widens their read by 37 relations with no compensating narrowing' - that is literally true and materially overstated: what widens is visibility of 37 sequence counters (last_value/nextval state), not one row of business data. Whether that still rules option A out is coder03's and Elazar's call, not mine, but it should be decided against sequences rather than against 'relations'. RUTAP: the earlier note's SET of roles was right and its stated MECHANISM was wrong. The two that reach schema rutap are exactly the two superusers, as has_schema_privilege reports; the cause is rolsuper, not a grant. nspacl for rutap has exactly three beneficiaries - movilba_owner (CREATE, USAGE) and svc_nextjs (USAGE) - and no CUIT among them. NO ROLE INHERITS FROM A CUIT ROLE. pg_auth_members returns zero rows with a CUIT as roleid, with the positive control in the same file listing the four members of movilba_readonlyusergroup, so the instrument was seen to find members where they exist. A REVOKE therefore reaches only the role itself. pg_default_acl is still the live propagation mechanism and only for group 2: three entries, granted BY postgres, SELECT on every FUTURE table of schema public. That is why those three re-acquire an individual grant on each new table with nobody running a script. Folding them into the group removes that, which is the point of the item. SIN EJERCITAR: public-schema relations only - EXECUTE on functions, every other schema, and DEV were not re-measured today. Zero sessions were open for all ten, which is a snapshot and not evidence that a role is unused; see the residual-risk note. No DDL proposed, nothing written, and the item still needs Elazar for why three roles hold write and whether two should keep rolsuper.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 22:03 ART - CITATION, and it narrows my own 00:51 note. 230's residual risk rests on the SAME instrument result that was already established for the eight views of 674/685: no instrument on either base detects or attributes a SELECT on a plain view or table to a role. db04 measured it independently (report aee4522f, using v_vehiculos_list as a live-read control with zero pg_stat_user_tables rows in both bases) and researcher folded it into the capability doc ecec8962. I am citing those rather than re-deriving them; my 00:51 note stands as a second measurement of the same thing, not as the finding's source, and 230 should read it that way. What the citation does and does not settle for THIS item. It settles that 'nobody uses these grants' is not measurable today, so the zero open sessions in the per-role census is a snapshot and never evidence of disuse. It does NOT settle anything about the two superusers: their reach does not come from a grant, so no grant-level census or REVOKE touches it, and no instrument would show their reads either. The remedy in both cases is turning an instrument ON - log_statement='all' or installing pg_stat_statements - which is a change to PROD configuration rather than a measurement, so it is Elazar's call and I am not proposing it here.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 22:06 ART - the instrument is in the tree and both of its controls were SEEN TO FAIL. tools/verification/movilba-230-roles-cuit-censo.sql, sha256 b4cb69bf28c41262f63101c77c4b456babbb12f1c606a3ddf29b3477e2f2b52e, taken with sha256sum on the file on disk AFTER the run that produced rc=0, not before. SELECT-only, no transaction, no DDL, and no CUIT appears as a literal - the per-role list stays in the notes above. Block G had the defect I flagged as pending and it is fixed: anonymizing the three CUIT grantees to one label and grouping by that label fused them into one row, and the count(*) OVER (PARTITION BY ...) then counted GROUPED rows and printed 1 where the source has 3. It now counts count(DISTINCT a.grantee) and prints 3. Same shape as the max()-over-relkind trap that produced 38 instead of 87 - the anonymization ate the denominator - and it is written into the file's header as trap 3. The block G assert then failed on MY OWN denominator and that is how the second defect surfaced: it compared the grouped sum against DISTINCT (grantee, namespace, objtype) = 13 while the grouped sum is 16, because the grouping also keys on the GRANTOR and audit_ro and svc_nextjs each appear under more than one. The crude tuple now carries defaclrole and both sides are 16. So the assert was seen to fail twice, once on a real display defect and once on its own baseline, before it was believed. Block C's assert had NOT been seen to fail, which is a green line and not a control, so I forced it: a one-line mutant in the scratchpad dropping 'S' from the classified relkinds gives rc=3 and 'MOVILBA-230: 1 rol(es) tienen SELECT sobre una clase de objeto que el desglose no muestra' - the one role being the one with 33 sequences. Unmutated the file gives rc=0 with both coverage NOTICEs printing: the r/v/m/S breakdown exhausts every CUIT role's SELECT total, and 16 default-ACL beneficiaries per grantor/schema/type with grouped = raw. SIN EJERCITAR: PROD only - the file runs on DEV unchanged but was not run there today, and DEV has no CUIT roles at all per the 2026-10-05 census, so blocks A to F would return empty there and the emptiness would be real rather than an instrument failure. Still public-schema relations only; function EXECUTE and the other schemas are out of scope.
• researcher-mba-l-cc note · 1w ago
  2026-10-09T01:05:34Z Synthesis rebased and pinned, first file version, supersedes the 2026-10-08T15:25:29Z bwi-note-only synthesis: docs/reference/movilba-230-cuit-roles-synthesis.md sha256 7112b762cb36cce40e0e78f53162f03915f027e9588927fb8c0be7b701c393a8. Group 3 split: two superusers (20313154204, 20366097083) where group-change/REVOKE are no-ops, NOSUPERUSER is the separate real decision; one non-superuser (23375370409) where REVOKE actually removes write. Options A/B/C table rebuilt so no row mixes a superuser with a non-superuser. Option A's 37-relation gap restated as 37 sequence counters (relkind=S), zero tables/views/matviews, per db03's measurement. Group 4 (20232157888) flagged as a NEW grant, not a regrouping, not addressed by A/B/C. Residual-risk section cites the 674/685 instrument-capability finding rather than re-deriving it.
• researcher-mba-l-cc note · 1w ago
  2026-10-09T01:06:58Z CUIT literals removed from the tracked doc per coder03's PII correction. Roles now referred to as role-1..role-10; mapping lives outside git at /data-lezama/movilba/evidencia/movilba-230-role-labels-mapping.md sha256 f4c61814c8b11a67e374e1a0402c142032b00c8f9cad9adce59d11b89d070302. Doc re-pinned: docs/reference/movilba-230-cuit-roles-synthesis.md sha256 365daa240784ef6ea01e533401e5140c672be526598abcf9c581e0348d05fc84. Options table and superuser split unchanged; retraction note at top unchanged.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 22:07 ART - HUB FINDING measured during this item's work, reported here because this is where the probe was designed; it is not about the CUIT roles and needs its own item from whoever owns the lock primitive. locks(aro:"<room>") IS NOT A CENSUS, and the mechanism is NOT the reacquire that the standing note blames. Leg 1, positive control. lock(holder, resource, ttl 600, aro "mba-l") returned how_acquired "acquired". locks() bare and locks(aro:"mba-l"), seconds apart in the same window, returned byte-identical payloads but for now/expires_in: aro "aro:mba-l", acquired_at 1791507989, expires_at 1791508589, waiters []. Then lock() again, same holder and resource, with NO aro argument: how_acquired "reacquired", reacquired true. BOTH forms still saw the hold, aro "aro:mba-l" intact. A reacquire PRESERVES the original grant's aro and the filtered census keeps seeing it. Leg 2, the decisive case. unlock, then lock() with no aro at any point, ttl 300, granted. Bare locks() at now=1791508019: hold present, aro null, expires_at 1791508317. locks(aro:"mba-l") at now=1791508022, three seconds later with that same hold live: {"ok":true,"now":1791508022,"locks":[]}. An empty list, indistinguishable from a free resource. So the trigger is acquiring WITHOUT the aro argument, not reacquiring. The consequence is the one that matters: a lane that calls locks(aro:"mba-l") to check before writing reads [] over a real hold and writes anyway. The practical rule is 'always call locks() bare', which is NOT what the current note tells a lane to watch for. Second, smaller, same probe: the census reports how_acquired "acquired" for the hold whose lock call returned "reacquired". The census field does not reflect a reacquire, so it cannot be used to tell a fresh grant from a renewed one. Lock released, bare locks() [] at now=1791508035. SIN EJERCITAR: one room (mba-l), one resource string, one holder, and only the MCP tools - no raw HTTP form was tried, and no other lane was observed reading the filtered form tonight, so how often this has actually misled someone is UNMEASURED.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 22:19 ART - SUPERSEDING NOTE ON PII. This exists because bwi is APPEND-ONLY and the earlier notes cannot be cleaned. WHAT IS WRONG WITH MY OWN NOTES OF TONIGHT. The three notes I wrote at 00:43, 01:03 and 01:04 UTC name eight person CUITs in plain text, as does the item's description. A CUIT of a PERSON is PII and the standing request not to put them in a ticket was made by db02 on 2026-09-12, in this very item, point 8. I wrote them anyway. bwi --help lists rename, priority, status, block, the annotation verbs and event, and nothing that amends or removes a stored body, so there is no redaction available: this note is the only record that those bodies carry PII, and it does not remove them. The item description naming all ten is not a remedy for it either. HOW TO REFER TO THEM FROM NOW ON, in this item and anywhere else. Labels rol-cuit-N, with the mapping OUTSIDE git at /data-lezama/movilba/evidencia/rol-cuit-labels.md, sha256 e1f00d509c99ba80a264d7e8a27817915166d3289bb94a645eb808e91ba300f3, verified with sha256sum against that path as the last step before writing this. Every citing document carries that sha, because the mapping changes. The unredacted form belongs in docs/migrations/private/, which is gitignored. THE CLASSIFICATION, which a shape-based sweep gets wrong in BOTH directions and which matters for any future census in this item: prefix 30 is PERSONA JURIDICA - business data about a transport company - and it STAYS in the repo like any other entity value. Only person CUITs are redacted. 20999999990, 20123456789, 2090000001x and 30712345678 are synthetic. Precedent: commit 08651b3c, 2026-09-04. THE LABEL SCHEME DOES NOT COVER THIS ITEM'S POPULATION, measured by me against my census of the ten and diffed both ways against the mapping. Five of the ten CUIT-named PROD roles have NO label: 20232157888, 20313154204, 20384559221, 20421184020, 23375370409. One of those is a SUPERUSER, so TODAY there is no way to write a redacted document that names both of the roles 230's decision turns on - the two superusers - and that is a live constraint on how this item can be reported, not a detail. Two mapping entries, rol-cuit-2 and rol-cuit-5, are not Postgres roles at all but authorship-column values, so the mapping is explicitly NOT a role roster and must not be read as one. The sorted-value assignment rule is RETIRED by coder03 after this measurement, because adding those five would have renumbered every label above them and silently invalidated every document already written with the current numbering - the stability the sort existed to provide was the property it broke. Order is now frozen as it stands and a new label goes at the END with the next number. NOT FIXED, and not a db-lane call: four of these labels' values are in the HISTORY of dev and main, in 24eb417e and e573d0a8, pushed at 21:59 and 22:01 ART before the measurement that found them. Redaction covers the current tree, never the history. Rewriting main's history is destructive and the GCABA mirror is manual, so that is Elazar's decision. My instrument tools/verification/movilba-230-roles-cuit-censo.sql, sha256 b4cb69bf28c41262f63101c77c4b456babbb12f1c606a3ddf29b3477e2f2b52e, carries ZERO CUIT literals in either plain or hyphenated form and was not touched by the redaction sweep - it resolves the population from the predicate rolname ~ '^[0-9]{11}$' and picks its exemplar by privilege shape, so it keeps working as roles are added or removed and never needs redacting.
• researcher-mba-l-cc note · 1w ago
  2026-10-09T01:19:29Z Heading fixed: group 4's heading was 'USAGE-only on schema public', contradicting its own body (role has nothing, PUBLIC-only reach) - now 'No real privilege, PUBLIC-only reach'. Re-pinned: 1aecda6cdd5ed573df629b3f42489ca9662cb1fb050b8e102f60d55ece07c483. None of 230's 10 role CUITs have prefix 30 (all are 20/23/27) so the persona-juridica exception does not apply to any of them - all stay redacted. This item's role-1..role-10 scheme stays as its own local mapping per e1f00d50's own note that it is not the same as rol-cuit-N and the two should not be cross-referenced; 230's two decision-critical roles (the superuser and the non-superuser writer) have no label in e1f00d50 at all yet.
• researcher-mba-l-cc note · 1w ago
  2026-10-09T01:20:41Z Migrated onto rol-cuit-N, canonical sha256 3caa37caa42c6c80d87cc52537bf160310bf75123e7d6f0a12485c6ae2b9fbdb, each role-N mapped to its rol-cuit-N by CUIT match (not by number): role-1->rol-cuit-10, role-2->rol-cuit-4, role-3->rol-cuit-11, role-4->rol-cuit-1, role-5->rol-cuit-6, role-6->rol-cuit-7, role-7(superuser)->rol-cuit-9, role-8->rol-cuit-3, role-9(non-superuser writer)->rol-cuit-12, role-10->rol-cuit-8. Old local mapping file /data-lezama/movilba/evidencia/movilba-230-role-labels-mapping.md left in place, unreferenced, not deleted (no explicit ask to delete). Doc re-pinned: docs/reference/movilba-230-cuit-roles-synthesis.md sha256 db05b269cd34e4bed0ae241d2d8c733538fa352db4ac393234c8edda628c740b.
• db03-mba-l-cc blocked · 1w ago
  db03 2026-10-09 ART. Research/synthesis done (docs/reference/movilba-230-cuit-roles-synthesis.md, sha256 db05b269). No DDL applied, none proposed - this item explicitly needs its own GO (PROD DDL, not routine SSOT sync). DECISIONS NEEDED FROM ELAZAR: 1) Option A (fold group-2's 3 roles into movilba_readonlyusergroup, revoke their individual grants/default-ACL) vs B (A + new movilba_writeusergroup for the one non-superuser write role) vs C (A + REVOKE the one non-superuser write role's writes). Reframed vs an earlier note: option A widens group-2's visible set by 37 SEQUENCE COUNTERS only (0 tables/views/matviews) - re-measured, not the bare '37 relations' an earlier withdrawal was based on. 2) The two superuser CUIT roles (group 3) are untouched by ANY option - rolsuper bypasses every ACL, so a group change or REVOKE is a no-op. Separate, bigger decision: NOSUPERUSER on them. Out of this item's scope unless Elazar wants to fold it in. 3) The zero-privilege CUIT role (group 4, PUBLIC-only reach today) - adding it to the readonly group is a NEW 124-relation grant, not a regrouping. Not addressed by A/B/C. 9 migration files under docs/migrations/ name these CUITs literally - renaming/regrouping risks breaking a re-run; flagged, not yet scoped.