Openrsync – die rsync-Implementierung des OpenBSD-Teams

• openrsync ist eine Implementierung von rsync unter der BSD-(ISC)-Lizenz und wurde inzwischen in die OpenBSD-Basis integriert
• Es ist mit aktuellem rsync kompatibel; für Tests wird rsync 3.1.3 verwendet, funktioniert aber mit Unterstützung für Protokoll 27
• Da nicht die vollständige Menge der rsync-Kommandozeilenargumente, sondern nur ein Teil der Argumente unterstützt wird, sollten beim gemeinsamen Einsatz von openrsync und rsync nur Flags verwendet werden, die beide Seiten unterstützen
• Das offiziell unterstützte Betriebssystem ist OpenBSD; es enthält jedoch Portabilitäts-Glue, damit es auch auf anderen UNIX-Systemen kompiliert und ausgeführt werden kann
• Die Standarddokumentation besteht aus Manual-Pages; Protokolldetails stehen in rsync(5) und rsyncd(5), die Utility-Dokumentation in openrsync(1)
• Das Projekt wurde als Teil von rpki-client(1) für OpenBSD geschrieben und von NetNod, IIS.SE, SUNET und 6connect finanziert
• Die Installation erfolgt auf gewöhnlichen UNIX-Systemen mit ./configure, make, make install und kollidiert nicht mit einer bestehenden rsync-Installation
• Der rsync-Algorithmus ist in Sender und Receiver aufgeteilt; der Sender erstellt die Liste der Quelldateien und Metadaten, und beide Seiten sortieren die Dateinamen lexikografisch, um Einträge positionsbasiert zu referenzieren
• Bei der normalen Dateisynchronisierung wird eine Datei übersprungen, wenn Dateigröße und Änderungszeit identisch sind; andernfalls werden pro Block fester Größe ein schneller Adler-32-artiger 4-Byte-Hash und ein langsamer MD4-16-Byte-Hash verwendet, um die geänderten Daten zu rekonstruieren
• Die Blockgröße ist standardmäßig der gerundete Wert der Quadratwurzel der gesamten Dateigröße; die Mindestgröße beträgt 700 B, und das Ergebnis der Quadratwurzel wird aus unbekannten Gründen auf ein Vielfaches von 8 aufgerundet
• Eine Sitzung ist in einen vom Benutzer gestarteten Client und einen auf dem Zielsystem laufenden Serverprozess aufgeteilt; der Server kann bei Bedarf über ssh(1) gestartet werden oder als dauerhaft laufender Netzwerk-Daemon arbeiten
• Anders als bei rsync, wo der Generator als separater Prozess neben dem Receiver läuft, fasst openrsync Generator und Receiver in einem Prozess zusammen und verarbeitet Lese- und Schreibanfragen über eine Event-Loop
• In puncto Sicherheit begrenzt OpenBSDs pledge(2) Systemoperationen je nach Ausführungsmodus, und unveil(2) erlaubt nur Dateisystemzugriffe unterhalb des Zielverzeichnisses
• Im Servermodus wird der MD4-Hash-Seed nicht mit time(3), sondern mit arc4random(3) erzeugt
• Portierbar auf Linux (glibc·musl), FreeBSD, NetBSD, Mac OS X und OmniOS; GitHub CI testet die Architekturen x86_64, aarch64 und s390x, wobei die zentrale Einschränkung bei der Portierung darin besteht, Sicherheitsfunktionen zu erreichen, die OpenBSDs pledge und unveil entsprechen

[GN⁺]

Hacker-News-Kommentare

• Die Erklärung, dass, wenn der entfernte Server Quelle oder Ziel ist, der Client mit fork(2) ein Kind erzeugt, dann per ssh(1) auf dem entfernten Host den Server openrsync startet und Client und Server über eine socketpair(2)-Pipe kommunizieren, ist etwas unklar, wie das genau funktionieren soll
  Vermutlich ist gemeint, dass das geforkte Kind die Verbindung über das Socket-Paar an den Elternprozess weitergibt oder die Standard-Ein-/Ausgabe mit der Socket-Paar-„Pipe“ verbindet und dann ssh per exec startet
  Aber das ist ein bisschen so, als würde man sagen, man fährt mit dem Auto zum Flughafen und dann behaupten, man fahre mit dem Auto nach Australien

• Seit der Ankündigung von openrsync nutze ich es hier und da, und mit der Zeit ist es definitiv besser geworden. Ich freue mich auf den Punkt, an dem ich es vollständig verwenden kann
  Allerdings gibt es in meinem Nutzungsmuster einen Punkt, an dem es nicht mit Samba-rsync übereinstimmt: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
  Erwartet hätte ich, dass auf dem Remote-System die Datei /tmp/services angelegt wird, tatsächlich wird aber /tmp/services/services erzeugt
  Normales Verzeichnis-Mirroring wie -av -e ssh /path/to/src/ example.com:/path/to/dst/ verhält sich wie bei Samba-rsync

  • Dieses Verhalten scheint auch mit „normalem“ rsync übereinzustimmen. Um nur den Inhalt zu synchronisieren, braucht services vermutlich einen Trailing Slash
    Korrektur: Mein „normales“ rsync war in Wirklichkeit auch das openrsync von macOS
  • Entscheidend ist, ob auf dem Ziel bereits ein Verzeichnis /tmp/services existierte
    Einer der verwirrendsten Aspekte von rsync ist die Behandlung von Verzeichnissen und Trailing Slashes
  • Mit einem Trailing Slash an der Quelle wird innerhalb des Verzeichnisses kopiert, ohne ihn wird das Verzeichnis selbst kopiert. Soweit ich weiß, ist das bei POSIX-Tools allgemein ziemlich standardmäßig
  • Als jemand, der von rsync seit unzähligen Jahren schikaniert wird, verstehe ich den Impuls, aber das Erzeugen des zweiten services ergibt viel mehr Sinn und ist der sicherere Standardwert
    Wenn es eine Gelegenheit gibt, die rsync-Defaults in eine weniger wahnsinnige Richtung zu ändern, sollte man künftige Generationen vor diesem Durcheinander bewahren

• Wenn man sieht, dass es in der rsync-Codebasis zuletzt plötzlich einen Anstieg von Vibe-Coding-Commits gab und dadurch sogar Regressionen entstanden sind, dann sind das sehr gute Nachrichten

  • rsync war immer robust, also wollte ich solche Aussagen zunächst ignorieren, aber nach einem Upgrade ist tatsächlich mein Backup-Skript kaputtgegangen
    In den neuesten GitHub-Issues sind viele Bugs gesammelt, die in den letzten zwei Patches eingeführt wurden, einschließlich eines monströsen Commits von rund 9.000 Zeilen, der vermutlich nicht einmal viel gebracht hat
    LLMs machen das Schreiben von Code schneller und einfacher, aber die eigentliche wichtige Arbeit war immer das Denken. Ich verstehe nicht, warum man so alte und vertrauenswürdige Software kaputtmacht

• Für alle, die den Entwicklungshintergrund dieses Pakets brauchen: Dieses Projekt wird derzeit als Teil eines RPKI-Validators entwickelt
  https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

• Es gibt auch eine Go-Implementierung von Michael Stapelberg / dem Gokrazy-Team: https://github.com/gokrazy/rsync

  • Vom Gokrazy-Team zu sprechen heißt allerdings praktisch Michael Stapelberg : )
    https://github.com/gokrazy/rsync/graphs/contributors

• Der Kern der eigentlichen Portierungsarbeit besteht darin, die Sicherheitsfunktionen nachzubilden, die OpenBSDs pledge(2) und unveil(2) bieten. Sie sind ein entscheidender Bestandteil der Systemfunktionen
  Ohne diese Funktionen würde das System beliebige Daten aus dem öffentlichen Netzwerk annehmen
  https://justine.lol/pledge/
  In Alpine Linux edge scheint pledge nicht vorhanden zu sein. Hat jemand pledge unter Linux getestet? Verstehe ich das Risiko falsch, openrsync ohne pledge zu verwenden, oder richtet sich der Beitrag nur an OpenBSD-Nutzer?

  • Linux hat weder pledge noch unveil oder Capsicum in dieser Form. Stattdessen gibt es cgroups, Namespaces und allerlei andere Dinge, die man kombinieren muss, um Ähnliches zu erreichen
    Linux wurde nicht als Isolationsfunktion entworfen, die das Gesamtkonzept über bestimmte Systemaufrufe und Kernel-Pfade bereitstellt, sondern eher so, dass immer wieder verschiedene Systeme hinzugefügt und miteinander kombiniert wurden, um Sandboxing oder Funktionseinschränkungen zusammenzubauen
    Heutzutage scheint es unter Linux auch neue Funktionen wie Landlock zu geben, aber vermutlich werden sie eher auf bestehenden Linux-Grundbausteinen aufgebaut als komplett neu geschaffen
    Mit „chaotisch“ ist wahrscheinlich gemeint, dass alles überall verstreut ist. Es gibt zu viele Wege, etwas zu verriegeln, und um herauszufinden, welcher der beste ist, muss man tief in jedes Subsystem einsteigen. Das steht im Kontrast zu nur ein oder zwei einfachen Systemaufrufen
  • Über der zitierten Stelle steht: „Das einzige offiziell unterstützte Betriebssystem ist OpenBSD, weil es über erhebliche Sicherheitsfunktionen verfügt“
    Und darunter steht: „Mit FreeBSDs Capsicum dürfte es machbar sein, aber die Sicherheitsmechanismen von Linux sind ein Chaos, und um es wirklich abzusichern, braucht es Expertenarbeit“
    Portabel bedeutet hier also, dass es kompiliert und läuft, nicht dass es dieselben Sicherheitsfunktionen bietet
    Es wäre schön, wenn pledge/unveil ins Linux-Upstream kämen, aber ich rechne nicht damit
  • Das Zitat ist so stark vereinfacht, dass es fast völlig falsch wirkt
    Anders als die Aussage „Ohne diese Funktionen würde das System beliebige Daten aus dem öffentlichen Netzwerk annehmen“ legen pledge und unveil nicht fest, ob beliebige Daten angenommen werden. Sie begrenzen, was ein kompromittierter Prozess tun kann
    Im Abschnitt Security wird das korrekt erklärt, deshalb weiß ich nicht, woher diese Formulierung kommt

• Diese Version wird seit macOS 15.0 verwendet

  • War es 15.0? Ich meine mich zu erinnern, dass es in einer der kleineren 15.x-Versionen eingeführt wurde, und ich erinnere mich daran, dass einige Skripte unerklärlich kaputtgingen
    Korrektur: Lustigerweise wurde es zwar in 15.0 aufgenommen, aber die inkompatible Änderung, die Dinge kaputtmacht, hat man sich offenbar bis 15.4 aufgehoben. https://apple.stackexchange.com/a/479297

• Da das aktuelle rsync-Protokoll nicht unterstützt wird, gibt es keine Unterstützung für 64-Bit-Zeitstempel, weshalb auf neueren Dateisystemen Metadaten tatsächlich nicht synchronisiert werden können

• Ich frage mich, warum der Name so gewählt wurde. Openrsync klingt für mich wie eine Open-Source-Alternative zu einem Closed-Source-Programm
  Aber war Rsync nicht ohnehin GPL? Bedeutet das einfach, dass es wegen der freizügigeren Lizenz als „offener“ gilt?

  • Leute aus dem OpenBSD-Umfeld würden wohl sagen, dass die GPL weniger offen ist, weil sie verlangt, GPL auch auf abgeleitete Werke anzuwenden
  • Unter Projekten mit enger Verbindung zu OpenBSD gibt es viele Namen, die mit open beginnen, etwa openssh, openbgpd, openntpd oder opensmtpd