- archive/internal/wormstore.Store: Put schreibt einmalig (chmod 0400 danach, ErrAlreadyExists bei Ueberschreibversuch inkl. DB-seitiger Sperre gegen Wettlaufsituationen), GetVerified prueft SHA-256 bei jedem Zugriff, KEINE Delete-Funktion (strukturelle API-Grenze) - migrations/0007_worm_objects: append-only Metadatentabelle - AC2/Pruefung 3 vor Umsetzung praezisiert: Schutz ueber Go-API, kein absoluter Schutz gegen root (Nutzerentscheidung: kein chattr +i, nicht portabel/nicht ehrlich als absolut behauptbar) - Reflection-Test beweist strukturell: keine Loesch-Methode vorhanden - zusaetzlich echter Nachweis auf 131 als Nicht-Root-Betriebsnutzer (sudo -u nexarch): direkter Ueberschreibversuch scheitert real, Automatiktest selbst laeuft als root und uebersprang diesen Teil bewusst Pruefungen siehe archive/docs/RET-04-PRUEFPROTOKOLL.md
67 lines
3.8 KiB
Markdown
67 lines
3.8 KiB
Markdown
# RET-04 – Prüfprotokoll: WORM-Speicher-Garantie (Append-only)
|
||
|
||
Voraussetzung RET-01 – bereits Fertig.
|
||
|
||
## Grenzen des Schutzes (bewusst dokumentiert, nicht behauptet)
|
||
|
||
Nach Nutzerentscheidung (Option 1) beschränkt sich der technische Schutz
|
||
auf zwei Ebenen, beide EHRLICH begrenzt dokumentiert statt als absolut
|
||
verkauft:
|
||
|
||
1. **Dateisystem-Schreibschutz (`chmod 0400`)** — schützt zuverlässig
|
||
gegen den Betriebs-Nutzer der Dienste (`nexarch`, kein root), NICHT
|
||
gegen root/CAP_DAC_OVERRIDE. Ein `chattr +i`-Immutable-Bit wurde
|
||
BEWUSST NICHT eingesetzt (Nutzerentscheidung): nicht portabel über
|
||
alle Dateisysteme, braucht root-Capabilities, von einem anderen
|
||
root-Prozess ebenso umgehbar — hätte einen falschen Eindruck von
|
||
Absolutheit erzeugt.
|
||
2. **Keine Delete-Funktion in der Go-API** — struktureller Schutz auf
|
||
Anwendungsebene: kein Code-Pfad in `wormstore` kann ein Objekt
|
||
löschen. Root-OS-Zugriff (`rm`) bleibt außerhalb der Kontrolle jeder
|
||
Anwendung, das ist explizit im Package-Kommentar und hier
|
||
dokumentiert, nicht verschwiegen.
|
||
|
||
Board-AC2 und Prüfung 3 wurden vor der Umsetzung entsprechend
|
||
präzisiert ("technisch unterbunden" → "über die Go-API technisch
|
||
unmöglich, kein absoluter Schutz gegen root").
|
||
|
||
## Umsetzung
|
||
|
||
- `archive/migrations/0007_worm_objects.up/down.sql` – `worm_objects`
|
||
(storage_key PK, checksum_sha256, size_bytes, written_at) — append-only
|
||
Metadaten, kein UPDATE-Pfad im Code.
|
||
- `archive/internal/wormstore.Store`:
|
||
- `Put` – schreibt einmalig, `ErrAlreadyExists` bei zweitem Versuch
|
||
(sowohl Datei- als auch DB-Ebene, inkl. Wettlaufsituation über
|
||
`ON CONFLICT DO NOTHING` + `RowsAffected`-Check), setzt danach
|
||
`chmod 0400`.
|
||
- `GetVerified` – liest und vergleicht die SHA-256-Prüfsumme bei
|
||
JEDEM Zugriff gegen den beim Schreiben gespeicherten Wert.
|
||
- **Kein `Delete`** — bewusst, siehe oben.
|
||
|
||
## Prüfungen
|
||
|
||
| # | Prüfung | Ergebnis |
|
||
|---|---|---|
|
||
| 1 | Direkter Überschreibversuch am Speicherpfad wird abgewiesen | **bestanden** – `TestPut_DirectOverwriteAttemptIsRejected`: API-Ebene (`ErrAlreadyExists`) real getestet; zusätzlich ECHTER Nachweis auf 131 als Nicht-Root-Nutzer (`sudo -u nexarch`, dem tatsächlichen Betriebsnutzer der Dienste): direkter Schreibversuch auf eine `chmod 0400`-Datei schlägt real mit "Permission denied" fehl, Inhalt bleibt unverändert. Der Automatik-Test selbst läuft auf 131 als root (`os.Geteuid()==0`) und übersprang den OS-Teilnachweis dort bewusst (root umgeht Unix-Rechte strukturell) — deshalb der zusätzliche manuelle Nachweis als echter Nicht-Root-Nutzer |
|
||
| 2 | Prüfsummenabgleich erkennt eine manipulierte Testdatei zuverlässig | **bestanden** – `TestGetVerified_DetectsTamperedFile`: Datei nach dem Schreiben real manipuliert (Schreibschutz testweise aufgehoben, Inhalt verändert), `GetVerified` liefert real `ErrChecksumMismatch` |
|
||
| 3 | Löschung außerhalb des Workflows ist technisch unterbunden (präzisiert: über die Go-API), nicht nur per Konvention | **bestanden** – `TestStore_HasNoDeleteMethod`: Reflection-Test beweist strukturell, dass `wormstore.Store` KEINE Lösch-Methode besitzt — kein Kommentar/keine Konvention, sondern eine compile-time-nachweisbare API-Grenze |
|
||
|
||
## Build/Test-Ergebnis (192.168.1.131)
|
||
|
||
```
|
||
go build ./... -> clean
|
||
go vet ./... -> clean
|
||
golangci-lint run ./... -> 0 issues
|
||
go test ./... -p 1 -> alle Archive-Pakete bestanden (inkl. wormstore)
|
||
```
|
||
|
||
## Gesamtergebnis
|
||
|
||
**Bestanden.** Alle drei (vor Umsetzung ehrlich präzisierten)
|
||
Akzeptanzkriterien und Pflichtprüfungen real erfüllt — inklusive eines
|
||
zusätzlichen, außerplanmäßigen manuellen Nachweises als echter
|
||
Nicht-Root-Betriebsnutzer, weil der automatisierte Test auf 131 als
|
||
root lief und den entscheidenden OS-Teilnachweis sonst nicht ehrlich
|
||
hätte erbringen können.
|