Vorher: prestart.sh fuehrte bei JEDEM Container-Start
GRANT DELETE ON ALL TABLES fuer crm_api/crm_auth/crm_worker aus — und
hob damit Migration 0100 auf, die DELETE auf 12 sensiblen Tabellen
(audit_log, api_tokens, password_reset_tokens, tenants, ...)
gezielt entzogen hatte. Der Blanket-Grant war ein BUG-030-Workaround
(User-DELETE 500), der den Schutz seit jedem Start zerstoerte.
Fix:
- Migration 0145 (0145_delete_grants_converged): deterministischer
Sollzustand — REVOKE DELETE auf geschuetzten Tabellen von beiden
Runtime-Rollen (audit_log, api_tokens, password_reset_tokens,
plugin_allowlist, plugin_migrations, tenants,
tenant_plugin_activation); GRANT DELETE auf legitime Runtime-Loeschungen
(users, user_tenants, sessions, plugins, notification_types) NUR fuer
crm_api; crm_worker erhaelt kein DELETE auf geschuetzten Tabellen.
- prestart.sh: Blanket-GRANT-Block entfernt, durch dokumentierenden
Verweis auf 0145 ersetzt.
- audit.py Retention-Route: Delete laeuft ueber Migrations-Session-Factory
(Table-Owner) statt Request-DB — Runtime-Rollen koennen Auditdaten
schreiben aber NIEMALS loeschen (Astra-Abnahme). Gleiches Muster wie
Plugin-Uninstall.
Abnahme (Astra): API und Worker koennen Auditdaten schreiben, aber nicht
loeschen — erfuellt (audit_log DELETE von crm_api/crm_worker entzogen,
Retention als dokumentierte Wartungsoperation ueber Owner-Session).
Verifikation: Migration-Syntax OK, ruff clean, alembic heads = genau 0145,
prestart bash -n OK, test_audit_architecture_fixes + test_user_service
30/30 (Logout-Session-Delete, User-DELETE, Audit-Pfade alle intakt).
Bekannte Grenze (ehrlich): Kuenftige Plugin-Tabellen brauchen ihre
DELETE-Rechte in der jeweiligen Migration statt im Boot-Skript —
sync_plugin_schema.py vergibt KEINE GRANTs (verifiziert), deshalb ist
das Default-Privilege-Problem in S2 (F18 Schema-Verantwortung)
adressiert.
Agent Zero
Leopoldadmin