From 926e5498123cf6b1ca646af3ab3cd1a8cbac5a18 Mon Sep 17 00:00:00 2001 From: sysops Date: Sun, 30 Aug 2026 02:35:23 +0200 Subject: [PATCH] docs(core): RBAC-06 Grant-Verifikation und Netzausfall-Hinweis ergaenzt nexarch_core-Rechte auf policy_rules/policy_rule_changes real ueber information_schema.role_table_grants verifiziert (dauerhaft, nicht von postgres-Eigentuemerschaft abhaengig). Push zu Gitea zum Commit- Zeitpunkt durch externen Netzwerkausfall (TCP 443/80 auf gitea.perlbach24.de nicht erreichbar) blockiert, kein Code-Fehler - Board-Status bleibt bis zum tatsaechlichen Push auf Backlog. --- docs/RBAC-06-PRUEFPROTOKOLL.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/docs/RBAC-06-PRUEFPROTOKOLL.md b/docs/RBAC-06-PRUEFPROTOKOLL.md index 4fc61be..fc66fe3 100644 --- a/docs/RBAC-06-PRUEFPROTOKOLL.md +++ b/docs/RBAC-06-PRUEFPROTOKOLL.md @@ -62,7 +62,24 @@ angrenzender Bereiche). - Reale Rechtevergabe-Lücke gefunden und behoben: `policy_rules`/ `policy_rule_changes` waren auf `nexarch_registry` bereits von einem früheren Testlauf unter der Rolle `postgres` angelegt worden, - `nexarch_core` hatte keine Rechte darauf — `GRANT` nachgezogen + `nexarch_core` hatte keine Rechte darauf — `GRANT` nachgezogen und + NACHTRÄGLICH VERIFIZIERT (nicht nur ausgeführt und angenommen): + `information_schema.role_table_grants` bestätigt `nexarch_core` hat + dauerhaft SELECT/INSERT/UPDATE/DELETE auf `policy_rules` und + SELECT/INSERT auf `policy_rule_changes` — der Endpunkt hängt NICHT + von der zufälligen `postgres`-Eigentümerschaft ab, sondern von einem + eigenen, geprüften Grant für die tatsächlich im Betrieb genutzte + Rolle (`NEXARCH_POLICY_ADMIN_DSN` in `/etc/nexarch/policy-api.env` + verwendet `nexarch_core`). Dieser Grant ist Teil des Deploy-Vorgangs, + nicht Teil von RBAC-02s Migration (deren Ticket bereits Fertig ist, + hier nicht nachträglich verändert) — ein künftiges Fresh-Deploy muss + ihn wiederholen, dokumentiert hier als Betriebsschritt. +- **Push zu Gitea vorübergehend nicht möglich**: `gitea.perlbach24.de` + war zum Zeitpunkt des Commits über TCP 443/80 nicht erreichbar (Ping + auf den Host erfolgreich, HTTP(S)-Ports timeout) — externer + Netzwerk-/Dienstausfall, KEIN Code- oder Konfigurationsfehler dieses + Tickets. Board-Status blieb bewusst auf „Backlog“, bis der Push + tatsächlich durchgeführt wurde (kein Status-Flip ohne Push). - Realer End-zu-Ende-Test via `curl`: 401 ohne Token, `{"allowed":false}` für unbekannte Kombination, `{"allowed":true}` nach echtem `Grant`, Testregel anschließend entfernt