syncova-backup/packages/repository/immutability_linux.go
Jerrit Fritzsche 610719c316
Some checks failed
CI / Backend (Go) (push) Failing after 3m7s
CI / Frontend (React/TypeScript) (push) Successful in 37s
CI / Sicherheitsprüfungen (push) Successful in 44s
Syncova Backups V1
Enterprise-Backup-, Recovery-, Verification-, Security- und
Monitoring-Plattform fuer Proxmox VE, Windows, Linux und Dateisysteme.

Der Leitsatz, der fast jede Entscheidung erklaert: Ein Backup gilt erst als
vertrauenswuerdig, wenn Integritaet geprueft und Wiederherstellbarkeit
nachgewiesen wurde. Deshalb steigt ein Wiederherstellungspunkt erst nach einem
tatsaechlich durchgefuehrten Restore-Test auf "recoverable", und Unbekanntes
geht in keine Bewertung als "gut" ein.

Umfang (Phasen 0-23):

- Repository Engine: inhaltsadressierte Bloecke, atomares Commit-Protokoll,
  Katalogaufbau allein aus den Manifesten — ohne Datenbank
- Backup Engine: inhaltsabhaengiges Chunking, Deduplizierung trotz
  Verschluesselung, zstd, AES-256-GCM, Streaming mit Gegendruck
- Agenten fuer Windows und Linux mit Auftragsabholung (Pull-Modell)
- Proxmox-Provider mit beiden Zugriffswegen auf die Sicherungsarchive
- Scheduler, Recovery Engine mit Pruefpunkt, Verification, Unveraenderlichkeit
- Weboberflaeche, Kennzahlen, Meldungen, Berichte, Security Center,
  Ransomware-Heuristik (meldet, handelt nie)
- Disaster Recovery, Haertung, Leistungsmessung, Chaos Testing
- Eingefrorene Vertraege fuer API, Migrationen, Backup-Format und Repository
- Auslieferungspaket fuer linux/amd64, linux/arm64 und windows/amd64

Nicht enthalten und als solches gekennzeichnet: Kapazitaetsprognose, Backup
Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und ACLs.

Gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die
systemd-Einheit und der verpflichtende Proxmox-Meilenstein — ob eine
wiederhergestellte VM startet, ist ungeprueft. Einzelheiten in CHANGELOG.md
und docs/release-candidate.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 09:10:54 +02:00

59 lines
1.9 KiB
Go

//go:build linux
package repository
import (
"os"
"golang.org/x/sys/unix"
)
// linuxImmutableFlag ist das Unveraenderlich-Kennzeichen des Dateisystems.
//
// Der Wert steht als FS_IMMUTABLE_FL in <linux/fs.h>; x/sys fuehrt ihn nicht,
// weshalb er hier benannt wird statt als nackte Zahl im Code zu stehen.
const linuxImmutableFlag = 0x00000010
// immutableFlagSupported meldet, ob dieses System ein Unveraenderlich-Kennzeichen kennt.
//
// Linux kennt es auf ext2/3/4, xfs und btrfs. Ob es sich setzen laesst, haengt
// zusaetzlich an der Berechtigung CAP_LINUX_IMMUTABLE — deshalb ist die
// Unterstuetzung hier nur die halbe Auskunft. Die andere Haelfte liefert die
// Messung in MeasureEnforcement, die es tatsaechlich versucht.
func immutableFlagSupported() bool {
return true
}
// setImmutableFlag setzt oder entfernt das Unveraenderlich-Kennzeichen.
func setImmutableFlag(filePath string, shouldBeImmutable bool) error {
// O_RDONLY genuegt: Die Kennzeichen haengen am Inode, nicht am Inhalt. Eine
// bereits unveraenderliche Datei liesse sich zum Schreiben gar nicht oeffnen
// — das Entfernen des Kennzeichens waere damit unmoeglich.
fileHandle, openError := os.OpenFile(filePath, os.O_RDONLY, 0)
if openError != nil {
return openError
}
defer func() { _ = fileHandle.Close() }()
currentFlags, readError := unix.IoctlGetInt(int(fileHandle.Fd()), unix.FS_IOC_GETFLAGS)
if readError != nil {
return &os.PathError{Op: "ioctl(FS_IOC_GETFLAGS)", Path: filePath, Err: readError}
}
updatedFlags := currentFlags &^ linuxImmutableFlag
if shouldBeImmutable {
updatedFlags = currentFlags | linuxImmutableFlag
}
if updatedFlags == currentFlags {
return nil
}
if writeError := unix.IoctlSetPointerInt(int(fileHandle.Fd()), unix.FS_IOC_SETFLAGS, updatedFlags); writeError != nil {
return &os.PathError{Op: "ioctl(FS_IOC_SETFLAGS)", Path: filePath, Err: writeError}
}
return nil
}