Entwicklung in schreibgeschützten Sandboxes: Wie OverlayFS, Symlink-Wälder und Git-Alternates das Kopieren von Dateien ersetzen

In modernen Software- und Sicherheitsarchitekturen ist die Kapselung von Prozessen ein Standard. Container in Docker und Podman mit dem Parameter --read-only, Kubernetes-Pods mit gesetztem readOnlyRootFilesystem: true, Google gVisor (runsc), Bazel-Build-Umgebungen und macOS-Seatbelt-Profile binden Quellcode-Repositories standardmäßig schreibgeschützt ein. Dasselbe Prinzip gilt für autonome Programmier-Agenten wie Claude Code, OpenAI Codex oder Test-Runner in Benchmarks wie SWE-bench. Das Basissystem und der Quelltext des Hosts bleiben geschützt, damit fehlerhafte Befehle oder bösartige Payloads keine Dateien auf dem Entwicklungsrechner manipulieren.

Dieser Schutz blockiert jedoch reguläre Entwicklungsschritte. Sobald Compiler, Test-Frameworks oder Agenten Dateien verändern oder temporäre Caches anlegen wollen, bricht die Ausführung mit dem Fehler OS Error 30: Read-only file system (EROFS) ab. Wie eine grundlegende Isolation auf Betriebssystemebene aufgebaut wird, beschreibt der Leitfaden Sichere Arbeitsumgebung auf macOS. Setup Guide für virtuelle Maschinen mit Lima. Das Zusammenspiel verschiedener Schutzschichten für Terminal-Abläufe analysiert der Beitrag Mein Security-Stack. Lima, Trivy, LLM Guard und warum mein Agent seine Seele signiert. Wenn Ausführungsumgebungen gegen gefährliche Payloads gehärtet werden, wie in Mein AI-Virenscanner hat mich gerade vor mir selbst beschützt an Shell-Scannern gezeigt, bildet das unveränderliche Dateisystem die vorderste Schranke. Diese Trennung verlangt deterministische Mechanismen, wie sie für typisierte Schnittstellen in Typisierte Entscheidungen statt Fließtext: was Jev ist und wann es das richtige Werkzeug ist dargelegt sind.

Stand aller Angaben: Oktober 2026. Grundlage dieser Analyse sind die Linux-Kernel-Spezifikation für OverlayFS, die Sandbox-Architekturen von Google gVisor und Google Bazel, Apple-APFS-Systemaufrufe, Git-Core-Dokumentationen sowie Messungen des CERN.

Naives Kopieren nach /tmp scheitert an RAM-Grenzen, Ephemeral-Storage-Quotas und atomaren Dateisystem-Schranken

Der naheliegende Reflex, das schreibgeschützte Projektverzeichnis vor Beginn der Arbeit mit dem Befehl cp -r in ein beschreibbares Verzeichnis wie /tmp zu duplizieren, führt in produktiven Umgebungen zu vier technischen Konflikten:

1. RAM-Verbrauch bei Ramdisks: In isolierten Containern liegt /tmp häufig auf einem flüchtigen Dateisystem im Arbeitsspeicher (tmpfs). Eine vollständige Dateikopie belegt physischen RAM proportional zur Projektgröße. Bei umfangreichen Repositories oder großen Datenmengen beendet der Linux-Kernel den Prozess unmittelbar durch den Out-of-Memory-Killer (OOM-Kill).

2. Speicher-Eviction in Kubernetes: Der Kubelet-Dienst überwacht den lokalen Speicherverbrauch ephemerer Pods über den Systemaufruf stat anhand der belegten Datenblöcke (stat.st_blocks * block_size). Wird ein Codebestand dupliziert, überschreitet der Pod das definierte Speicherlimit (requests.ephemeral-storage). Das System markiert den Pod als überlastet und leitet eine Zwangsräumung (Pod Eviction) ein.

3. Latenz und Inode-Mangel: Softwareprojekte mit tief verschachtelten Abhängigkeiten umfassen oft mehr als 100.000 Einzeldateien. Das rekursive Kopieren solcher Strukturen erzeugt erhebliche I/O-Wartezeiten und bindet Prozessorleistung. Auf Partitionen mit festen Grenzwerten für Datei-Indexknoten führt die Duplikation zum Fehler ENOSPC (No space left on device), obwohl auf dem Datenträger freie Speicherkapazität vorhanden ist.

4. Dateisystem-Grenzen beim Verschieben: Versucht ein Entwicklungswerkzeug, bearbeitete Dateien aus dem temporären Ordner per atomarem Systemaufruf rename(2) in das Quellverzeichnis zurückzubewegen, quittiert das Betriebssystem die Operation mit dem Fehler EXDEV: Invalid cross-device link. Atomare Umbenennungen sind nach POSIX-Standard ausschließlich innerhalb desselben Dateisystems zulässig.

Kernel-Overlays mit Metacopy reduzieren den I/O- und Speicheraufwand um 95 Prozent

Die etablierte Lösung auf Betriebssystemebene ist das Overlay-Dateisystem (OverlayFS) des Linux-Kernels. Es kombiniert zwei getrennte Verzeichnisbäume zu einem gemeinsamen Einhängepunkt:

1. lowerdir: Das ursprüngliche Verzeichnis wird als unveränderliche Basisschicht schreibgeschützt eingebunden.

2. upperdir: Ein flüchtiges, beschreibbares Verzeichnis nimmt Änderungen auf.

3. workdir: Ein leeres Hilfsverzeichnis auf demselben Dateisystem wie das upperdir, das der Kernel für atomare Dateioperationen vor der Sichtbarkeit im Zielpfad benötigt.

Der Einhängebefehl im Linux-Terminal lautet:

mount -t overlay overlay -o lowerdir=/readonly/source,upperdir=/tmp/upper,workdir=/tmp/work /workspace

Lesezugriffe leitet der Kernel direkt an das lowerdir weiter. Wird eine Datei schreibend geöffnet (open(O_WRONLY) oder open(O_RDWR)), führt das Dateisystem ein sogenanntes Copy-Up aus: Der Kernel kopiert die betroffene Datei in das beschreibbare upperdir. Alle folgenden Schreibvorgänge verbleiben im flüchtigen Ordner. Das Basisverzeichnis bleibt unberührt.

Wird eine Datei aus der Read-Only-Schicht gelöscht, erzeugt OverlayFS im beschreibbaren Verzeichnis eine Zeichengerätedatei mit der Major- und Minor-Gerätenummer 0/0 (c 0 0), einen sogenannten Whiteout. Dieser Eintrag verdeckt die Originaldatei im Einhängepunkt, ohne den schreibgeschützten Datenträger zu modifizieren.

Die Effizienz dieses Verfahrens hängt von der Behandlung von Dateimetadaten ab. Seit Linux-Kernel 4.19 existiert die Mount-Option metacopy=on. Bei Datei-Attributänderungen (chmod, chown, touch) oder Verzeichnis-Scans kopiert der Kernel nur den Verzeichniseintrag (Dentry) mit den neuen Attributen in den oberen Layer. Die eigentlichen Datenblöcke verbleiben im schreibgeschützten Speicher.

Ein Benchmark des CERN aus dem Juni 2024 (EP-SFT Analyse im CVMFS-Umfeld) belegt die Wirkung: Durch die Aktivierung von metacopy=on sinkt der I/O- und Speicheraufwand bei typischen Dateioperationen um bis zu 95 Prozent gegenüber vollständigen Kopierabläufen.

Für Container ohne Root-Rechte, bei denen der Kernel-Befehl mount durch Seccomp-Filter gesperrt ist, stellt das Werkzeug fuse-overlayfs eine Alternative dar. Entwickelt von Giuseppe Scrivano für unprivilegierte Podman-Umgebungen, verlagert es die Overlay-Logik über die Schnittstelle /dev/fuse in den User-Space. Bei hoher I/O-Frequenz entsteht ein geringer Mehraufwand gegenüber dem Kernel-Modul, der Ressourcenbedarf bleibt jedoch weit unter dem Niveau rekursiver Dateiduplikate.

Symlink-Wälder nach Bazel-Vorbild ersetzen Dateikopien in unprivilegierten Umgebungen vollständig

In restriktiven Ausführungsumgebungen fehlen Entwicklern und Agenten oft die Kernel-Rechte (CAP_SYS_ADMIN), um ein OverlayFS zu betreiben. Auch User-Namespaces (CLONE_NEWUSER) sind auf gehärteten Systemen häufig deaktiviert (unprivileged_userns_clone=0).

Für diesen Fall nutzt das Build-System Google Bazel in seiner processwrapper-sandbox eine reine POSIX-Lösung: sogenannte Symlink-Wälder (Symlink Forests). Das Prinzip lässt sich auf jedem Unix-System mit Bordmitteln nachbilden:

1. Verzeichnisstruktur spiegeln: Im beschreibbaren Arbeitsordner werden ausschließlich die Verzeichnisse des Quellbaums als reale Verzeichnisse angelegt.

2. Dateien verlinken: Jede Datei des Projekts wird als symbolischer Link auf die Originaldatei im schreibgeschützten Verzeichnis eingetragen.

Unter Linux übernimmt der Befehl cp -as diesen Schritt:

cp -as /readonly/source/. /writable/workspace

Auf Systemen ohne GNU-Erweiterungen (wie macOS) erfüllt das Werkzeug lndir denselben Zweck.

Die Arbeitsweise stützt sich auf das Verhalten moderner Toolchains beim Speichern von Änderungen. Compiler und Quelltext-Editoren überschreiben Zieldateien selten direkt über offene Dateideskriptoren. Stattdessen nutzen sie atomare Schreibmuster: Sie erstellen eine temporäre Datei (open(O_CREAT|O_EXCL)) und verschieben diese anschließend über den Systemaufruf rename(2) an den Zielort.

Durch diesen Aufruf wird der symbolische Link im beschreibbaren Arbeitsordner entfernt (Unlink-on-Write). An seiner Stelle entsteht eine eigenständige, beschreibbare Datei. Alle unveränderten Dateien bleiben symbolische Verweise, die jeweils weniger als 100 Byte Speicher für den Indexeintrag belegen. Der Speicherverbrauch eines Projekts mit mehreren Gigabytes an Quelltext sinkt vor der Bearbeitung auf wenige Megabyte für die Link-Struktur.

Git-Alternates entkoppeln Commit-Historie und Arbeitskopie mit unter einem Megabyte Speicherbedarf

Wenn Entwicklungsprozesse Versionskontrollbefehle wie git status, git diff, git branch oder git commit erfordern, scheitert die Arbeit in einer Read-Only-Sandbox sofort, sobald das Verzeichnis .git/ schreibgeschützt ist. Git verlangt Schreibzugriff auf die Lock-Dateien (index.lock, HEAD.lock) und die Objektdatenbank.

Die Git-Kernspezifikation (gitrepository-layout(5)) definiert dafür den Mechanismus der Git-Alternates:

1. Leeres Repository anlegen: Im beschreibbaren Scratchpad wird ein neues Git-Repository initialisiert:

   git init /tmp/scratch-repo

2. Objektdatenbank verknüpfen: In die Konfigurationsdatei .git/objects/info/alternates wird der absolute Pfad zum Objektverzeichnis des schreibgeschützten Stamm-Repositories eingetragen:

   echo "/readonly/repo/.git/objects" > /tmp/scratch-repo/.git/objects/info/alternates

3. Arbeitsstand bereitstellen: Über die Befehle git read-tree HEAD und git checkout-index -a -f wird der gewünschte Branch in den beschreibbaren Arbeitsordner geholt.

Durch diesen Ablauf erhält das Scratch-Repository vollen Lesezugriff auf die gesamte Versionshistorie, alle Blobs und alle Tree-Objekte des Stammprojekts. Es werden keine Git-Datenblöcke kopiert. Der initiale Speicheraufwand liegt bei unter einem Megabyte für die Basiskonfiguration.

Neue Commits, lokale Branches und Reflog-Einträge speichert Git isoliert in der lokalen Objektdatenbank des Scratchpads. Nach Abschluss der Arbeit lassen sich die Änderungen als Patch-Datei exportieren oder über einen Branch an ein zentrales Repository übertragen. Das ursprüngliche Repository auf dem Host bleibt während des gesamten Vorgangs unverändert.

Gezielte Umgebungsvariablen leiten Compiler-Caches und temporäre Artefakte vollständig aus dem Quellbaum um

Über 80 Prozent aller EROFS-Abbrüche in Read-Only-Sandboxes entstehen nicht durch manuelle Quelltext-Änderungen, sondern durch automatische Cache- und Build-Mechanismen moderner Programmiersprachen. Compiler und Runtimes versuchen standardmäßig, AST-Caches, Bytecode und temporäre Artefakte direkt neben den Quelldateien abzulegen.

Durch gezielte Umgebungsvariablen lässt sich dieser Schreibstrom vollständig in einen flüchtigen Zielordner umleiten:

# Python: Bytecode (__pycache__) umleiten (PEP 552)
export PYTHONPYCACHEPREFIX=/tmp/pycache

# Rust / Cargo: Build-Ausgaben (target/) entkoppeln
export CARGO_TARGET_DIR=/tmp/target

# Go: Modul- und Build-Caches auslagern
export GOCACHE=/tmp/gocache
export GOTMPDIR=/tmp/gotmp

# CMake: Quell- und Build-Baum trennen
cmake -S /readonly/source -B /tmp/build

# Node.js und pnpm: Cache- und Store-Pfade definieren
export npm_config_cache=/tmp/npm-cache
pnpm config set virtual-store-dir /tmp/.pnpm

In Python verhinderte das Fehlen einer solchen Konfiguration jahrelang den Betrieb auf unveränderlichen Dateisystemen. Mit PEP 552 und der Einführung von PYTHONPYCACHEPREFIX in Python 3.8 wurde der Standard geschaffen, kompilierte .pyc-Dateien anhand ihres Ursprungspfads in einer separaten Ordnerhierarchie abzulegen.

Auf Systemebene bieten moderne Dateisysteme hardwarenahe Klonfunktionen. Apple APFS unterstützt über den Systemaufruf clonefile(2) (im Terminal verfügbar über cp -cR) das Erstellen vollständiger Verzeichnisbäume in konstanter Laufzeit ($O(1)$). Die geklonten Dateien teilen sich dieselben physischen Speicherblöcke auf der SSD. Erst wenn Schreibvorgänge stattfinden, allokiert der APFS-Treiber neue Speicherblöcke für geänderte Blöcke. Unter Linux stellen Btrfs und XFS denselben Mechanismus über den Kernel-Ioctl FICLONE (Befehl: cp --reflink=always -R) bereit.

Autonome Programmier-Agenten schützen den Quellcode durch flüchtige Arbeitsbäume und Patch-Rückführung

Für autonome KI-Agenten wie Claude Code, OpenAI Codex oder Evaluierungs-Runner für Programmier-Benchmarks ist die Kapselung im Dateisystem eine kritische Sicherheitsanforderung:

1. Das Sicherheitsrisiko bei Schreibzugriff: Erhält ein autonomes Modell vollen Schreibzugriff auf das Stamm-Repository des Entwicklers, können fehlerhafte Befehle, Halluzinationen oder Prompt-Injection-Angriffe aus gelesenen Webseiten und Paketen den lokalen Code beschädigen oder sensible Daten löschen.

2. Das Funktionsdilemma bei reinem Schreibschutz: Wird dem Agenten eine starre Read-Only-Sandbox zugewiesen, scheitert er bei der ersten Testausführung, beim Anlegen von Zwischendateien oder beim Refactoring von Funktionen.

Die Lösung besteht in einem vierstufigen Ausführungsmuster:

1. Schreibgeschützte Bereitstellung: Das Host-Repository wird als Read-Only Bind Mount in den Container oder die virtuelle Maschine des Agenten eingebunden.

2. Initialisierung des flüchtigen Arbeitsbaums: Ein Startskript (wie das Werkzeug ro-arbeitsbaum) erzeugt im Scratchpad des Agenten automatisch eine Symlink-Farm oder ein Git-Alternate-Repository und setzt die Umgebungsvariablen für Cache-Umleitungen.

3. Isolierte Ausführung: Der Agent führt Tests durch, kompiliert Binärdateien und modifiziert Quelltexte im beschreibbaren Scratchpad.

4. Rückführung per Patch: Nach Abschluss der Aufgabenstellung generiert der Agent eine strukturierte Patch-Datei:

   git diff > /export/aenderung.patch

   Dieser Patch wird auf dem Host-System geprüft, bevor er in den Hauptzweig übernommen wird. Das Original-Repository bleibt vor unkontrollierten Eingriffen geschützt.

Was diese Analyse nicht leistet: Offene Fragen zu Inode-Quotas, OCI-Treibern und Virtualisierung

Die vorgestellten Verfahren basieren auf stabilen Kernel- und Toolchain-Spezifikationen. Für den produktiven Betrieb bleiben drei technische Aspekte offen, die vor einem flächendeckenden Einsatz geprüft werden müssen:

1. Inode-Limits bei tiefen Abhängigkeitsbäumen: Symlink-Wälder minimieren den Speicherplatzverbrauch, erzeugen jedoch für jede verlinkte Datei einen eigenen Indexeintrag. Bei Projekten mit unbereinigten Abhängigkeitsordnern entstehen zehntausende Symlinks. In Linux-Containern mit festen Inode-Quotas kann dies trotz freiem Festplattenspeicher zum Abbruch von Build-Prozessen führen.

2. Fehlende OCI-Standards für ephemere Agenten-Dateisysteme: Die Open Container Initiative (OCI) definiert Schnittstellen für Read-Only-Mounts und Rootfs-Schichten, bietet jedoch keinen standardisierten Container-Storage-Treiber, der OverlayFS, Symlink-Wälder und Git-Alternates für kurzlebige KI-Agenten-Sitzungen bündelt. Entsprechende Abläufe müssen derzeit über Wrapper-Skripte im Container-Startprozess realisiert werden.

3. Latenzen über Virtualisierungsgrenzen: Auf macOS-Systemen, die Linux-Container über virtuelle Maschinen (wie Lima) betreiben, werden Host-Verzeichnisse über virtiofs oder das 9p-Protokoll eingebunden. Wie stark sich die I/O-Latenz verhält, wenn ein OverlayFS innerhalb der Linux-VM auf einem über virtiofs gemounteten Read-Only-Hostpfad aufgesetzt wird, ist von der Dateigröße und Caching-Strategie des VM-Treibers abhängig und bedarf im Einzelfall empirischer Messungen.

Quellen

Alle Quellen abgerufen am 18.10.2026.

• [1] Linux Kernel Organization: „Documentation/filesystems/overlayfs.rst“, offizielle Spezifikation für OverlayFS, Lowerdir, Upperdir, Workdir und Metacopy: https://docs.kernel.org/filesystems/overlayfs.html
• [2] Ayush Ranjan (Google Open Source / gVisor Team): „Rootfs Overlay Architecture“, gVisor Architecture Blog, 08.05.2023: https://gvisor.dev/blog/2023/05/08/rootfs-overlay/
• [3] Google Bazel Team: „Sandboxing Architecture & processwrapper-sandbox“, offizielle Dokumentation zu Symlink Forests im Execroot, 2024 bis 2026: https://bazel.build/docs/sandboxing
• [4] Apple Inc.: „About Apple File System & clonefile Specification“, Apple Developer Documentation: https://developer.apple.com/documentation/foundation/about-apple-file-system
• [5] Git Project: „Git Alternates Specification (gitrepository-layout)“, offizielle Referenzdokumentation für objects/info/alternates: https://git-scm.com/docs/gitrepository-layout
• [6] Python Software Foundation: „PEP 552: Deterministic pycs and PYTHONPYCACHEPREFIX Specification“, Python 3.8 bis 3.13: https://peps.python.org/pep-0552/
• [7] The Rust Foundation: „The Cargo Book: Environment Variables (CARGO_TARGET_DIR)“, offizielle Cargo-Dokumentation: https://doc.rust-lang.org/cargo/reference/environment-variables.html
• [8] CERN / EP-SFT: „Benchmarking modern Overlay FS features“, CVMFS Analysis and Benchmarking Indico Report, Juni 2024: https://indico.cern.ch/event/1402909/
• [9] Giuseppe Scrivano / Red Hat: „fuse-overlayfs Specification“, Referenz-Implementierung für unprivilegierte Container: https://github.com/containers/fuse-overlayfs
• [10] Open Container Initiative (OCI): „OCI Runtime Specification v1.2.0“, Standards für Linux Namespaces und Read-Only Mounts: https://github.com/opencontainers/runtime-spec