QA-15 F-15 behoben: 10 bisher ungehaertete Archive-Backup/Reconcile/Scrub-Oneshot-Vorlagen bekommen Sandbox-Direktiven (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, passende ReadWritePaths). Neue getrennte Postgres-Laufzeit-Rolle (nexarch_tenant_runtime, ohne CREATEDB) statt der bisher gemeinsam genutzten CREATEDB-Rolle fuer die an alle Dienste ausgegebene Tenant-DSN.
Echter Fund waehrend der Haertung: tenantbackup-cli schrieb sein Protokoll ausserhalb des urspruenglich vorgesehenen ReadWritePaths-Bereichs -- entdeckt und behoben.
Alle 3 Pruefungen real durchgefuehrt:
Gehaertete Vorlagen starten real (2/10 voller Erfolg gegen echte Infra, 8/10 scheitern an echten Anwendungskonfigurationen, niemals an der Sandbox selbst)
Neuer echter Test TestProvision_RuntimeRoleHasNoCreateDB mit zwei tatsaechlich getrennten Rollen: Laufzeit-Rolle darf in eigener Tenant-DB schreiben, scheitert aber real an CREATE DATABASE
Gesamtsystem-Smoke-Test: 45/45 bestanden, GESAMT-FEHLER=0, Rueckbau identisch (erster Lauf zeigte scheinbare Fehler durch Portkollision mit einem parallel laufenden, unabhaengigen Fork auf demselben Host -- per Baseline-Vergleich gegen main als keine echte Regression bestaetigt)
Bestehende Tests: alle 20 Tests in internal/tenant unveraendert gruen (13 Aufrufstellen von NewProvisioner an neue Signatur angepasst). Kein Merge, kein Deploy.
QA-15 F-15 behoben: 10 bisher ungehaertete Archive-Backup/Reconcile/Scrub-Oneshot-Vorlagen bekommen Sandbox-Direktiven (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, passende ReadWritePaths). Neue getrennte Postgres-Laufzeit-Rolle (nexarch_tenant_runtime, ohne CREATEDB) statt der bisher gemeinsam genutzten CREATEDB-Rolle fuer die an alle Dienste ausgegebene Tenant-DSN.
Echter Fund waehrend der Haertung: tenantbackup-cli schrieb sein Protokoll ausserhalb des urspruenglich vorgesehenen ReadWritePaths-Bereichs -- entdeckt und behoben.
Alle 3 Pruefungen real durchgefuehrt:
1. Gehaertete Vorlagen starten real (2/10 voller Erfolg gegen echte Infra, 8/10 scheitern an echten Anwendungskonfigurationen, niemals an der Sandbox selbst)
2. Neuer echter Test TestProvision_RuntimeRoleHasNoCreateDB mit zwei tatsaechlich getrennten Rollen: Laufzeit-Rolle darf in eigener Tenant-DB schreiben, scheitert aber real an CREATE DATABASE
3. Gesamtsystem-Smoke-Test: 45/45 bestanden, GESAMT-FEHLER=0, Rueckbau identisch (erster Lauf zeigte scheinbare Fehler durch Portkollision mit einem parallel laufenden, unabhaengigen Fork auf demselben Host -- per Baseline-Vergleich gegen main als keine echte Regression bestaetigt)
Bestehende Tests: alle 20 Tests in internal/tenant unveraendert gruen (13 Aufrufstellen von NewProvisioner an neue Signatur angepasst). Kein Merge, kein Deploy.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
patrick
added 4 commits 2026-09-26 22:55:34 +02:00
10 bisher ungehaertete Archive-Backup/Reconcile/Scrub-Oneshot-Vorlagen
(deploy/systemd/) bekommen die etablierten Sandbox-Direktiven
(NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, ggf.
ReadWritePaths). Drei Vorlagen ohne Dateisystemzugriff (reconcile,
retention-notify, scrub) bekommen bewusst keine ReadWritePaths,
begruendet dokumentiert (S3-kompatible Storage-Abstraktion statt
lokaler Pfade).
Neue, getrennte Postgres-Laufzeit-Rolle (nexarch_tenant_runtime, OHNE
CREATEDB) statt der bisher gemeinsam genutzten CREATEDB-Rolle fuer
NEXARCH_TENANT_DSN_TEMPLATE. Provisioner.Provision() berechtigt die
neue Rolle je frisch angelegter Tenant-DB (GRANT CONNECT + Schema-
Rechte inkl. Default-Privileges), Tenant.DBDSN wird jetzt mit dieser
Rolle statt der CREATEDB-Rolle gebaut. Neue Umgebungsvariable
NEXARCH_TENANT_RUNTIME_DSN_TEMPLATE, deploy/install.sh legt die Rolle
automatisch an.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Alle Testaufrufe uebergeben adminDSNTemplate/runtimeDSNTemplate mit
demselben Wert (Testrolle bleibt Eigentuemerin, GRANT an sich selbst
ist ein no-op) -- keine Verhaltensaenderung in bestehenden Tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TestProvision_RuntimeRoleHasNoCreateDB belegt Akzeptanzkriterium 2 mit
zwei tatsaechlich getrennten Postgres-Rollen (nicht nur derselben
Rolle zweimal uebergeben wie in den uebrigen Testaufrufen): die
Laufzeit-Rolle darf in ihrer eigenen Tenant-DB schreiben, aber keine
neue Datenbank anlegen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Alle drei Pruefungen real durchgefuehrt und bestanden. Echter Fund
waehrend der Haertung (tenantbackup-cli-Protokollpfad ausserhalb des
Storage-Basispfads) dokumentiert und behoben. Der erste
Smoke-Test-Lauf zeigte scheinbare Fehler durch eine Portkollision mit
einem parallel laufenden Fork auf dem geteilten Host 204 -- per
Baseline-Vergleich und zweitem isoliertem Lauf als keine echte
Regression bestaetigt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
patrick
added 2 commits 2026-10-17 16:24:22 +02:00
PR #217 (OPS-12) war nicht mergefaehig: additiver Konflikt in Config{}
-- main hatte inzwischen ModuleDirectoryPath ergaenzt, OPS-12 ergaenzt
unabhaengig davon TenantRuntimeDSNTemplate. Beide Felder behalten,
keine inhaltliche Aenderung an der eigentlichen OPS-12-Logik.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der automatische Merge von PR #217 (OPS-12) gegen main liess
internal/tenant/provisioner.go::ProvisionWithID mit einem nicht mehr
existierenden Feld (p.dsnTemplate) zurueck und vergass dort den
grantRuntimeRole-Aufruf, den Provision() bereits hat -- echter
Build-Fehler, kein reiner Textkonflikt, git markierte ihn nicht als
Konflikt. Drei weitere Aufrufer von NewProvisioner (Migrationswerkzeug,
Cutover-Orchestrator, Test) riefen noch mit der alten Drei-Parameter-
Signatur auf. Alle auf die neue Vier-Parameter-Signatur (Admin-DSN +
Runtime-DSN) nachgezogen, wo keine eigene Runtime-DSN-Variable existiert
faellt auf dieselbe Vorlage zurueck (admin-only Werkzeuge).
Verifiziert auf Host 204: go build/vet sauber, betroffene Pakete
(tenant, migrationtenant, cutoverorchestrator, cor01-tenant-migrate)
gruen. Einziger verbleibender FAIL (TestAllHTTPServersUseHTTPHarden)
ist der bereits bekannte, unabhaengige Befund aus PR #345 (noch nicht
gemergt), keine neue Regression.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
QA-15 F-15 behoben: 10 bisher ungehaertete Archive-Backup/Reconcile/Scrub-Oneshot-Vorlagen bekommen Sandbox-Direktiven (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, passende ReadWritePaths). Neue getrennte Postgres-Laufzeit-Rolle (nexarch_tenant_runtime, ohne CREATEDB) statt der bisher gemeinsam genutzten CREATEDB-Rolle fuer die an alle Dienste ausgegebene Tenant-DSN.
Echter Fund waehrend der Haertung: tenantbackup-cli schrieb sein Protokoll ausserhalb des urspruenglich vorgesehenen ReadWritePaths-Bereichs -- entdeckt und behoben.
Alle 3 Pruefungen real durchgefuehrt:
Bestehende Tests: alle 20 Tests in internal/tenant unveraendert gruen (13 Aufrufstellen von NewProvisioner an neue Signatur angepasst). Kein Merge, kein Deploy.
🤖 Generated with Claude Code
Inhalt bereits in main enthalten (geprueft per merge_all_prs.sh: leerer Merge-Diff). Geschlossen ohne Merge.
Pull request closed