# Linux-Agent (Phase 6) Phase 6 teilt sich fast alles mit Phase 5 — dieselbe Aufnahme, dieselbe Lebendmeldung, dieselbe Auftragsübermittlung, dieselbe Engine. Was sie eigenständig macht, sind die Eigenheiten eines Unix-Dateisystems: Sockets, benannte Pipes, Gerätedateien, harte Verknüpfungen — und ein Dienstmodell, das sich einsperren lässt. ## Der Fund: Ein Socket ist kein Fehler Bis zu dieser Phase galt **jedes** Erfassungsproblem als übergangenes Objekt und machte den Lauf damit zum Teilfehler. Auch ein Socket. Auf einem Linux-System ist das ein Dauerzustand: In `/var/run` und `/tmp` liegen ständig Sockets. Wer `/var` sichert, bekäme bei **jedem** Lauf einen Teilfehler. Nach einer Woche klickt niemand mehr einen Teilfehler an — und dann fällt auch der echte nicht mehr auf. Dieselbe Alarmmüdigkeit, gegen die Phase 14 und 16 gebaut sind. Die Unterscheidung, die jetzt gilt: | Objekt | Ergebnis | Warum | | --- | --- | --- | | Nicht lesbare Datei | **Datenverlust** → Teilfehler | Dort waren Daten, und sie fehlen | | Gesperrtes Verzeichnis | **Datenverlust** → Teilfehler | Dasselbe | | Socket | Vermerk, kein Fehler | Endpunkt eines laufenden Prozesses, kein Inhalt | | Benannte Pipe (FIFO) | Vermerk, kein Fehler | Hat keinen Inhalt zum Sichern | | Block-/Zeichengerät | Vermerk, kein Fehler | Dasselbe | **Verschwiegen wird trotzdem nichts.** Die Zusammenfassung nennt sie auch im Erfolgsfall: ``` Erfolgreich: 4 Dateien, 1 Verzeichnisse gesichert. 2 Objekt(e) ohne sicherbaren Inhalt (Sockets, Pipes, Gerätedateien) wurden übergangen; das ist kein Fehler. ``` Und die Meldung benennt den Typ in Worten. `prw-r--r--` sagt einem Betreiber nichts; „benannte Pipe (FIFO)" sagt ihm, dass er nichts zu tun hat. ### Was der Agent mit einer FIFO **nicht** tut Er liest sie nicht. Das ist der klassische Backup-Bug: Ein Leseversuch auf einer benannten Pipe ohne Schreiber blockiert **für immer**. Die Erfassung entscheidet anhand des Dateityps, bevor sie öffnet — ein Test mit Zeitgrenze hält das fest. ## Symbolische Verweise werden erfasst, nicht verfolgt Ein Verweis kommt als Verweis ins Backup und wird als Verweis zurückgeschrieben. Verfolgte die Erfassung ihn, geriete sie bei einem Verweis auf ein übergeordnetes Verzeichnis in eine Schleife — und ein Verweis nach `/` zöge das ganze System ins Backup. ## Harte Verknüpfungen: der Inhalt kommt zurück, die Verknüpfung nicht Zwei Namen derselben Datei erscheinen als **zwei Dateien**. Der Inhalt liegt dank Deduplizierung nur einmal im Repository — der Platzbedarf im Backup ist also derselbe. Nach einer Wiederherstellung sind es jedoch **zwei unabhängige Dateien**: ``` Quelle: 2 Verknüpfungen Ziel: 1 Verknüpfung ``` Das kostet Platz am Ziel und ändert die Bedeutung: Eine Änderung an der einen wirkt nicht mehr auf die andere. Für die meisten Anwendungsfälle ist das unerheblich; wer Paketverwaltungen oder Deduplizierungsbäume sichert, sollte es wissen. Umsetzbar wäre es — Inode-Nummer erfassen und beim Zurückschreiben `link()` statt Kopie —, aber es griffe in das Manifestformat ein. Es steht hier als benannte Grenze, nicht als Versehen. ## Die systemd-Einheit hatte drei Fehler `deployment/syncova-agent.service` war gut gehärtet und **hätte nicht funktioniert**: **`--state /var/lib/syncova-agent`** — das ist ein Verzeichnis. Der Parameter erwartet eine Datei. Der Agent hätte beim Start gemeldet, er sei bereits registriert (ein vorhandenes Verzeichnis sieht für ihn wie eine Zustandsdatei aus), und wäre ohne Token gelaufen. **Kein `ReadWritePaths` für das Repository.** Bei `ProtectSystem=strict` ist das gesamte Dateisystem nur lesbar. Der Agent hätte die Quelle vollständig gelesen und gehasht — und dann keinen einzigen Block ablegen können. Der Fehler wäre erst am Ende des Laufs aufgetreten. **`RestrictAddressFamilies` ohne `AF_UNIX`.** Auf Systemen mit `systemd-resolved` oder `nscd` läuft die Namensauflösung über einen Unix-Socket. Ohne `AF_UNIX` findet der Agent seinen Server nicht und meldet einen Netzfehler, während das Netz einwandfrei arbeitet. Alle drei sind behoben. Der Repositorypfad ist an die eigene Anlage anzupassen — liegt das Repository auf einer Freigabe, gehört deren Einhängepunkt in `ReadWritePaths`. > Die Einheit ist weiterhin **nicht auf einem Linux-System geprüft**. > `systemd-analyze verify` gibt es auf macOS nicht. ## Was die Härtung leistet Der Agent liest fremde Daten und spricht mit dem Netz — genau die Art Dienst, die man einsperrt: - **`CAP_DAC_READ_SEARCH` statt root.** Er darf fremde Dateien lesen, sonst nichts. Der Unterschied ist beträchtlich: Lesen ist etwas anderes als Alleskönnen. - **`ProtectSystem=strict`, `ProtectHome=read-only`**, Schreibrechte nur auf Zustand und Repository. - **`MemoryDenyWriteExecute`, `RestrictSUIDSGID`, `NoNewPrivileges`, Systemaufruffilter** — die üblichen Riegel gegen Ausnutzung eines Fehlers im Dienst selbst. - **`Nice=10`, `IOSchedulingClass=idle`** — ein Backup soll dem laufenden Betrieb nicht die Maschine wegnehmen. - **Das Schlüsselmaterial steht in einer Datei, nicht in `Environment=`.** Ein `Environment=` im Unit-File ist für jeden Benutzer über `systemctl show` lesbar. ## Nachweis Auf einem Quellverzeichnis mit gewöhnlichen Dateien, einer harten Verknüpfung, einem symbolischen Verweis, einer benannten Pipe, einem Unix-Socket und einem gesperrten Verzeichnis: ```text Erfassung 4 Dateien, 2 Objekte ohne sicherbaren Inhalt vermerkt Sicherung Erfolg (Exit 0) — kein Teilfehler wegen Socket und Pipe Restore 4 Dateien bitgenau, Symlink erhalten, Rechte erhalten Sonderdateien im Ziel: keine — korrekt Harte Verknüpfung: Quelle 2, Ziel 1 — dokumentierte Grenze ``` Der gesperrte Ordner erzeugte dabei erwartungsgemäß einen Rechtefehler und damit einen Teilfehler — bis er freigegeben wurde. Genau diese Unterscheidung ist der Kern der Phase. ## Was offen bleibt - **Die systemd-Einheit ist ungeprüft.** Sie ist inhaltlich korrigiert, aber nie auf einem Linux-System geladen worden. - **Erweiterte Attribute und ACLs werden nicht gesichert.** POSIX-ACLs, SELinux-Kontexte und `xattr` gehen verloren. Für eine Wiederherstellung auf demselben System ist das meist unerheblich, für eine Systemwiederherstellung nicht. - **Keine Sicherung offener Dateien mit konsistentem Stand.** Es gibt keinen Schattenkopie-Mechanismus wie VSS unter Windows; eine Datenbank, die während der Sicherung schreibt, landet in dem Zustand, in dem sie gerade ist. Für Datenbanken gehört ein eigener Ablauf davor (Dump oder Snapshot des Dateisystems). - **Harte Verknüpfungen werden aufgelöst** (siehe oben).