{
    "kind": 30023,
    "id": "5f26aea68fa63fa08955438e3373c0c616d1e73b6a8cd77e112b521a23dbb35d",
    "pubkey": "c1baf4f74cd829963828b1da8d73e52cc94caa6d8dc944f7ca450a75c4b3311f",
    "created_at": 1792307732,
    "tags": [
        [
            "title",
            "Entwicklung in schreibgesch\u00fctzten Sandboxes: Wie OverlayFS, Symlink-W\u00e4lder und Git-Alternates das Kopieren von Dateien ersetzen"
        ],
        [
            "d",
            "wie-kann-man-in-read-only-sandbox-umgebungen-mit-einschraenk"
        ],
        [
            "summary",
            "Effektives Arbeiten in Read-Only-Sandbox-Umgebungen: Wie OverlayFS mit Metacopy, Bazel-Symlink-W\u00e4lder, Git-Alternates und Cache-Umleitungen das Kopieren von Dateien \u00fcberfl\u00fcssig machen."
        ],
        [
            "published_at",
            "1792307732"
        ]
    ],
    "content": "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\u00e4\u00dfig schreibgesch\u00fctzt ein. Dasselbe Prinzip gilt f\u00fcr 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\u00fctzt, damit fehlerhafte Befehle oder b\u00f6sartige Payloads keine Dateien auf dem Entwicklungsrechner manipulieren.\n\nDieser Schutz blockiert jedoch regul\u00e4re Entwicklungsschritte. Sobald Compiler, Test-Frameworks oder Agenten Dateien ver\u00e4ndern oder tempor\u00e4re Caches anlegen wollen, bricht die Ausf\u00fchrung 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](https://stevennoack.de/artikel/sichere-arbeitsumgebung-macos-setup-guide/) f\u00fcr virtuelle Maschinen mit Lima. Das Zusammenspiel verschiedener Schutzschichten f\u00fcr Terminal-Abl\u00e4ufe analysiert der Beitrag [Mein Security-Stack. Lima, Trivy, LLM Guard und warum mein Agent seine Seele signiert](https://stevennoack.de/artikel/mein-security-stack/). Wenn Ausf\u00fchrungsumgebungen gegen gef\u00e4hrliche Payloads geh\u00e4rtet werden, wie in [Mein AI-Virenscanner hat mich gerade vor mir selbst besch\u00fctzt](https://stevennoack.de/artikel/llm-guard-ai-virenscanner/) an Shell-Scannern gezeigt, bildet das unver\u00e4nderliche Dateisystem die vorderste Schranke. Diese Trennung verlangt deterministische Mechanismen, wie sie f\u00fcr typisierte Schnittstellen in [Typisierte Entscheidungen statt Flie\u00dftext: was Jev ist und wann es das richtige Werkzeug ist](https://stevennoack.de/artikel/typisierte-entscheidungen-jev/) dargelegt sind.\n\nStand aller Angaben: Oktober 2026. Grundlage dieser Analyse sind die Linux-Kernel-Spezifikation f\u00fcr OverlayFS, die Sandbox-Architekturen von Google gVisor und Google Bazel, Apple-APFS-Systemaufrufe, Git-Core-Dokumentationen sowie Messungen des CERN.\n\n## Naives Kopieren nach /tmp scheitert an RAM-Grenzen, Ephemeral-Storage-Quotas und atomaren Dateisystem-Schranken\n\nDer naheliegende Reflex, das schreibgesch\u00fctzte Projektverzeichnis vor Beginn der Arbeit mit dem Befehl `cp -r` in ein beschreibbares Verzeichnis wie `/tmp` zu duplizieren, f\u00fchrt in produktiven Umgebungen zu vier technischen Konflikten:\n\n1. RAM-Verbrauch bei Ramdisks: In isolierten Containern liegt `/tmp` h\u00e4ufig auf einem fl\u00fcchtigen Dateisystem im Arbeitsspeicher (`tmpfs`). Eine vollst\u00e4ndige Dateikopie belegt physischen RAM proportional zur Projektgr\u00f6\u00dfe. Bei umfangreichen Repositories oder gro\u00dfen Datenmengen beendet der Linux-Kernel den Prozess unmittelbar durch den Out-of-Memory-Killer (OOM-Kill).\n2. Speicher-Eviction in Kubernetes: Der Kubelet-Dienst \u00fcberwacht den lokalen Speicherverbrauch ephemerer Pods \u00fcber den Systemaufruf `stat` anhand der belegten Datenbl\u00f6cke (`stat.st_blocks * block_size`). Wird ein Codebestand dupliziert, \u00fcberschreitet der Pod das definierte Speicherlimit (`requests.ephemeral-storage`). Das System markiert den Pod als \u00fcberlastet und leitet eine Zwangsr\u00e4umung (Pod Eviction) ein.\n3. Latenz und Inode-Mangel: Softwareprojekte mit tief verschachtelten Abh\u00e4ngigkeiten 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\u00fcr Datei-Indexknoten f\u00fchrt die Duplikation zum Fehler `ENOSPC` (No space left on device), obwohl auf dem Datentr\u00e4ger freie Speicherkapazit\u00e4t vorhanden ist.\n4. Dateisystem-Grenzen beim Verschieben: Versucht ein Entwicklungswerkzeug, bearbeitete Dateien aus dem tempor\u00e4ren Ordner per atomarem Systemaufruf `rename(2)` in das Quellverzeichnis zur\u00fcckzubewegen, quittiert das Betriebssystem die Operation mit dem Fehler `EXDEV: Invalid cross-device link`. Atomare Umbenennungen sind nach POSIX-Standard ausschlie\u00dflich innerhalb desselben Dateisystems zul\u00e4ssig.\n\n## Kernel-Overlays mit Metacopy reduzieren den I/O- und Speicheraufwand um 95 Prozent\n\nDie etablierte L\u00f6sung auf Betriebssystemebene ist das Overlay-Dateisystem (OverlayFS) des Linux-Kernels. Es kombiniert zwei getrennte Verzeichnisb\u00e4ume zu einem gemeinsamen Einh\u00e4ngepunkt:\n\n1. `lowerdir`: Das urspr\u00fcngliche Verzeichnis wird als unver\u00e4nderliche Basisschicht schreibgesch\u00fctzt eingebunden.\n2. `upperdir`: Ein fl\u00fcchtiges, beschreibbares Verzeichnis nimmt \u00c4nderungen auf.\n3. `workdir`: Ein leeres Hilfsverzeichnis auf demselben Dateisystem wie das `upperdir`, das der Kernel f\u00fcr atomare Dateioperationen vor der Sichtbarkeit im Zielpfad ben\u00f6tigt.\n\nDer Einh\u00e4ngebefehl im Linux-Terminal lautet:\n\n```bash\nmount -t overlay overlay -o lowerdir=/readonly/source,upperdir=/tmp/upper,workdir=/tmp/work /workspace\n```\n\nLesezugriffe leitet der Kernel direkt an das `lowerdir` weiter. Wird eine Datei schreibend ge\u00f6ffnet (`open(O_WRONLY)` oder `open(O_RDWR)`), f\u00fchrt das Dateisystem ein sogenanntes Copy-Up aus: Der Kernel kopiert die betroffene Datei in das beschreibbare `upperdir`. Alle folgenden Schreibvorg\u00e4nge verbleiben im fl\u00fcchtigen Ordner. Das Basisverzeichnis bleibt unber\u00fchrt.\n\nWird eine Datei aus der Read-Only-Schicht gel\u00f6scht, erzeugt OverlayFS im beschreibbaren Verzeichnis eine Zeichenger\u00e4tedatei mit der Major- und Minor-Ger\u00e4tenummer 0/0 (`c 0 0`), einen sogenannten Whiteout. Dieser Eintrag verdeckt die Originaldatei im Einh\u00e4ngepunkt, ohne den schreibgesch\u00fctzten Datentr\u00e4ger zu modifizieren.\n\nDie Effizienz dieses Verfahrens h\u00e4ngt von der Behandlung von Dateimetadaten ab. Seit Linux-Kernel 4.19 existiert die Mount-Option `metacopy=on`. Bei Datei-Attribut\u00e4nderungen (`chmod`, `chown`, `touch`) oder Verzeichnis-Scans kopiert der Kernel nur den Verzeichniseintrag (Dentry) mit den neuen Attributen in den oberen Layer. Die eigentlichen Datenbl\u00f6cke verbleiben im schreibgesch\u00fctzten Speicher.\n\nEin 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\u00fcber vollst\u00e4ndigen Kopierabl\u00e4ufen.\n\nF\u00fcr 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\u00fcr unprivilegierte Podman-Umgebungen, verlagert es die Overlay-Logik \u00fcber die Schnittstelle `/dev/fuse` in den User-Space. Bei hoher I/O-Frequenz entsteht ein geringer Mehraufwand gegen\u00fcber dem Kernel-Modul, der Ressourcenbedarf bleibt jedoch weit unter dem Niveau rekursiver Dateiduplikate.\n\n## Symlink-W\u00e4lder nach Bazel-Vorbild ersetzen Dateikopien in unprivilegierten Umgebungen vollst\u00e4ndig\n\nIn restriktiven Ausf\u00fchrungsumgebungen fehlen Entwicklern und Agenten oft die Kernel-Rechte (`CAP_SYS_ADMIN`), um ein OverlayFS zu betreiben. Auch User-Namespaces (`CLONE_NEWUSER`) sind auf geh\u00e4rteten Systemen h\u00e4ufig deaktiviert (`unprivileged_userns_clone=0`).\n\nF\u00fcr diesen Fall nutzt das Build-System Google Bazel in seiner `processwrapper-sandbox` eine reine POSIX-L\u00f6sung: sogenannte Symlink-W\u00e4lder (Symlink Forests). Das Prinzip l\u00e4sst sich auf jedem Unix-System mit Bordmitteln nachbilden:\n\n1. Verzeichnisstruktur spiegeln: Im beschreibbaren Arbeitsordner werden ausschlie\u00dflich die Verzeichnisse des Quellbaums als reale Verzeichnisse angelegt.\n2. Dateien verlinken: Jede Datei des Projekts wird als symbolischer Link auf die Originaldatei im schreibgesch\u00fctzten Verzeichnis eingetragen.\n\nUnter Linux \u00fcbernimmt der Befehl `cp -as` diesen Schritt:\n\n```bash\ncp -as /readonly/source/. /writable/workspace\n```\n\nAuf Systemen ohne GNU-Erweiterungen (wie macOS) erf\u00fcllt das Werkzeug `lndir` denselben Zweck.\n\nDie Arbeitsweise st\u00fctzt sich auf das Verhalten moderner Toolchains beim Speichern von \u00c4nderungen. Compiler und Quelltext-Editoren \u00fcberschreiben Zieldateien selten direkt \u00fcber offene Dateideskriptoren. Stattdessen nutzen sie atomare Schreibmuster: Sie erstellen eine tempor\u00e4re Datei (`open(O_CREAT|O_EXCL)`) und verschieben diese anschlie\u00dfend \u00fcber den Systemaufruf `rename(2)` an den Zielort. \n\nDurch diesen Aufruf wird der symbolische Link im beschreibbaren Arbeitsordner entfernt (Unlink-on-Write). An seiner Stelle entsteht eine eigenst\u00e4ndige, beschreibbare Datei. Alle unver\u00e4nderten Dateien bleiben symbolische Verweise, die jeweils weniger als 100 Byte Speicher f\u00fcr den Indexeintrag belegen. Der Speicherverbrauch eines Projekts mit mehreren Gigabytes an Quelltext sinkt vor der Bearbeitung auf wenige Megabyte f\u00fcr die Link-Struktur.\n\n## Git-Alternates entkoppeln Commit-Historie und Arbeitskopie mit unter einem Megabyte Speicherbedarf\n\nWenn 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\u00fctzt ist. Git verlangt Schreibzugriff auf die Lock-Dateien (`index.lock`, `HEAD.lock`) und die Objektdatenbank.\n\nDie Git-Kernspezifikation (`gitrepository-layout(5)`) definiert daf\u00fcr den Mechanismus der Git-Alternates:\n\n1. Leeres Repository anlegen: Im beschreibbaren Scratchpad wird ein neues Git-Repository initialisiert:\n   ```bash\n   git init /tmp/scratch-repo\n   ```\n2. Objektdatenbank verkn\u00fcpfen: In die Konfigurationsdatei `.git/objects/info/alternates` wird der absolute Pfad zum Objektverzeichnis des schreibgesch\u00fctzten Stamm-Repositories eingetragen:\n   ```bash\n   echo \"/readonly/repo/.git/objects\" > /tmp/scratch-repo/.git/objects/info/alternates\n   ```\n3. Arbeitsstand bereitstellen: \u00dcber die Befehle `git read-tree HEAD` und `git checkout-index -a -f` wird der gew\u00fcnschte Branch in den beschreibbaren Arbeitsordner geholt.\n\nDurch diesen Ablauf erh\u00e4lt das Scratch-Repository vollen Lesezugriff auf die gesamte Versionshistorie, alle Blobs und alle Tree-Objekte des Stammprojekts. Es werden keine Git-Datenbl\u00f6cke kopiert. Der initiale Speicheraufwand liegt bei unter einem Megabyte f\u00fcr die Basiskonfiguration.\n\nNeue Commits, lokale Branches und Reflog-Eintr\u00e4ge speichert Git isoliert in der lokalen Objektdatenbank des Scratchpads. Nach Abschluss der Arbeit lassen sich die \u00c4nderungen als Patch-Datei exportieren oder \u00fcber einen Branch an ein zentrales Repository \u00fcbertragen. Das urspr\u00fcngliche Repository auf dem Host bleibt w\u00e4hrend des gesamten Vorgangs unver\u00e4ndert.\n\n## Gezielte Umgebungsvariablen leiten Compiler-Caches und tempor\u00e4re Artefakte vollst\u00e4ndig aus dem Quellbaum um\n\n\u00dcber 80 Prozent aller EROFS-Abbr\u00fcche in Read-Only-Sandboxes entstehen nicht durch manuelle Quelltext-\u00c4nderungen, sondern durch automatische Cache- und Build-Mechanismen moderner Programmiersprachen. Compiler und Runtimes versuchen standardm\u00e4\u00dfig, AST-Caches, Bytecode und tempor\u00e4re Artefakte direkt neben den Quelldateien abzulegen.\n\nDurch gezielte Umgebungsvariablen l\u00e4sst sich dieser Schreibstrom vollst\u00e4ndig in einen fl\u00fcchtigen Zielordner umleiten:\n\n```bash\n# Python: Bytecode (__pycache__) umleiten (PEP 552)\nexport PYTHONPYCACHEPREFIX=/tmp/pycache\n\n# Rust / Cargo: Build-Ausgaben (target/) entkoppeln\nexport CARGO_TARGET_DIR=/tmp/target\n\n# Go: Modul- und Build-Caches auslagern\nexport GOCACHE=/tmp/gocache\nexport GOTMPDIR=/tmp/gotmp\n\n# CMake: Quell- und Build-Baum trennen\ncmake -S /readonly/source -B /tmp/build\n\n# Node.js und pnpm: Cache- und Store-Pfade definieren\nexport npm_config_cache=/tmp/npm-cache\npnpm config set virtual-store-dir /tmp/.pnpm\n```\n\nIn Python verhinderte das Fehlen einer solchen Konfiguration jahrelang den Betrieb auf unver\u00e4nderlichen Dateisystemen. Mit PEP 552 und der Einf\u00fchrung von `PYTHONPYCACHEPREFIX` in Python 3.8 wurde der Standard geschaffen, kompilierte `.pyc`-Dateien anhand ihres Ursprungspfads in einer separaten Ordnerhierarchie abzulegen.\n\nAuf Systemebene bieten moderne Dateisysteme hardwarenahe Klonfunktionen. Apple APFS unterst\u00fctzt \u00fcber den Systemaufruf `clonefile(2)` (im Terminal verf\u00fcgbar \u00fcber `cp -cR`) das Erstellen vollst\u00e4ndiger Verzeichnisb\u00e4ume in konstanter Laufzeit ($O(1)$). Die geklonten Dateien teilen sich dieselben physischen Speicherbl\u00f6cke auf der SSD. Erst wenn Schreibvorg\u00e4nge stattfinden, allokiert der APFS-Treiber neue Speicherbl\u00f6cke f\u00fcr ge\u00e4nderte Bl\u00f6cke. Unter Linux stellen Btrfs und XFS denselben Mechanismus \u00fcber den Kernel-Ioctl `FICLONE` (Befehl: `cp --reflink=always -R`) bereit.\n\n## Autonome Programmier-Agenten sch\u00fctzen den Quellcode durch fl\u00fcchtige Arbeitsb\u00e4ume und Patch-R\u00fcckf\u00fchrung\n\nF\u00fcr autonome KI-Agenten wie Claude Code, OpenAI Codex oder Evaluierungs-Runner f\u00fcr Programmier-Benchmarks ist die Kapselung im Dateisystem eine kritische Sicherheitsanforderung:\n\n1. Das Sicherheitsrisiko bei Schreibzugriff: Erh\u00e4lt ein autonomes Modell vollen Schreibzugriff auf das Stamm-Repository des Entwicklers, k\u00f6nnen fehlerhafte Befehle, Halluzinationen oder Prompt-Injection-Angriffe aus gelesenen Webseiten und Paketen den lokalen Code besch\u00e4digen oder sensible Daten l\u00f6schen.\n2. Das Funktionsdilemma bei reinem Schreibschutz: Wird dem Agenten eine starre Read-Only-Sandbox zugewiesen, scheitert er bei der ersten Testausf\u00fchrung, beim Anlegen von Zwischendateien oder beim Refactoring von Funktionen.\n\nDie L\u00f6sung besteht in einem vierstufigen Ausf\u00fchrungsmuster:\n\n1. Schreibgesch\u00fctzte Bereitstellung: Das Host-Repository wird als Read-Only Bind Mount in den Container oder die virtuelle Maschine des Agenten eingebunden.\n2. Initialisierung des fl\u00fcchtigen 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\u00fcr Cache-Umleitungen.\n3. Isolierte Ausf\u00fchrung: Der Agent f\u00fchrt Tests durch, kompiliert Bin\u00e4rdateien und modifiziert Quelltexte im beschreibbaren Scratchpad.\n4. R\u00fcckf\u00fchrung per Patch: Nach Abschluss der Aufgabenstellung generiert der Agent eine strukturierte Patch-Datei:\n   ```bash\n   git diff > /export/aenderung.patch\n   ```\n   Dieser Patch wird auf dem Host-System gepr\u00fcft, bevor er in den Hauptzweig \u00fcbernommen wird. Das Original-Repository bleibt vor unkontrollierten Eingriffen gesch\u00fctzt.\n\n## Was diese Analyse nicht leistet: Offene Fragen zu Inode-Quotas, OCI-Treibern und Virtualisierung\n\nDie vorgestellten Verfahren basieren auf stabilen Kernel- und Toolchain-Spezifikationen. F\u00fcr den produktiven Betrieb bleiben drei technische Aspekte offen, die vor einem fl\u00e4chendeckenden Einsatz gepr\u00fcft werden m\u00fcssen:\n\n1. Inode-Limits bei tiefen Abh\u00e4ngigkeitsb\u00e4umen: Symlink-W\u00e4lder minimieren den Speicherplatzverbrauch, erzeugen jedoch f\u00fcr jede verlinkte Datei einen eigenen Indexeintrag. Bei Projekten mit unbereinigten Abh\u00e4ngigkeitsordnern entstehen zehntausende Symlinks. In Linux-Containern mit festen Inode-Quotas kann dies trotz freiem Festplattenspeicher zum Abbruch von Build-Prozessen f\u00fchren.\n2. Fehlende OCI-Standards f\u00fcr ephemere Agenten-Dateisysteme: Die Open Container Initiative (OCI) definiert Schnittstellen f\u00fcr Read-Only-Mounts und Rootfs-Schichten, bietet jedoch keinen standardisierten Container-Storage-Treiber, der OverlayFS, Symlink-W\u00e4lder und Git-Alternates f\u00fcr kurzlebige KI-Agenten-Sitzungen b\u00fcndelt. Entsprechende Abl\u00e4ufe m\u00fcssen derzeit \u00fcber Wrapper-Skripte im Container-Startprozess realisiert werden.\n3. Latenzen \u00fcber Virtualisierungsgrenzen: Auf macOS-Systemen, die Linux-Container \u00fcber virtuelle Maschinen (wie Lima) betreiben, werden Host-Verzeichnisse \u00fcber `virtiofs` oder das `9p`-Protokoll eingebunden. Wie stark sich die I/O-Latenz verh\u00e4lt, wenn ein OverlayFS innerhalb der Linux-VM auf einem \u00fcber `virtiofs` gemounteten Read-Only-Hostpfad aufgesetzt wird, ist von der Dateigr\u00f6\u00dfe und Caching-Strategie des VM-Treibers abh\u00e4ngig und bedarf im Einzelfall empirischer Messungen.\n\n## Quellen\n\nAlle Quellen abgerufen am 18.10.2026.\n\n\u2022 [1] Linux Kernel Organization: \u201eDocumentation/filesystems/overlayfs.rst\u201c, offizielle Spezifikation f\u00fcr OverlayFS, Lowerdir, Upperdir, Workdir und Metacopy: https://docs.kernel.org/filesystems/overlayfs.html  \n\u2022 [2] Ayush Ranjan (Google Open Source / gVisor Team): \u201eRootfs Overlay Architecture\u201c, gVisor Architecture Blog, 08.05.2023: https://gvisor.dev/blog/2023/05/08/rootfs-overlay/  \n\u2022 [3] Google Bazel Team: \u201eSandboxing Architecture & processwrapper-sandbox\u201c, offizielle Dokumentation zu Symlink Forests im Execroot, 2024 bis 2026: https://bazel.build/docs/sandboxing  \n\u2022 [4] Apple Inc.: \u201eAbout Apple File System & clonefile Specification\u201c, Apple Developer Documentation: https://developer.apple.com/documentation/foundation/about-apple-file-system  \n\u2022 [5] Git Project: \u201eGit Alternates Specification (gitrepository-layout)\u201c, offizielle Referenzdokumentation f\u00fcr objects/info/alternates: https://git-scm.com/docs/gitrepository-layout  \n\u2022 [6] Python Software Foundation: \u201ePEP 552: Deterministic pycs and PYTHONPYCACHEPREFIX Specification\u201c, Python 3.8 bis 3.13: https://peps.python.org/pep-0552/  \n\u2022 [7] The Rust Foundation: \u201eThe Cargo Book: Environment Variables (CARGO_TARGET_DIR)\u201c, offizielle Cargo-Dokumentation: https://doc.rust-lang.org/cargo/reference/environment-variables.html  \n\u2022 [8] CERN / EP-SFT: \u201eBenchmarking modern Overlay FS features\u201c, CVMFS Analysis and Benchmarking Indico Report, Juni 2024: https://indico.cern.ch/event/1402909/  \n\u2022 [9] Giuseppe Scrivano / Red Hat: \u201efuse-overlayfs Specification\u201c, Referenz-Implementierung f\u00fcr unprivilegierte Container: https://github.com/containers/fuse-overlayfs  \n\u2022 [10] Open Container Initiative (OCI): \u201eOCI Runtime Specification v1.2.0\u201c, Standards f\u00fcr Linux Namespaces und Read-Only Mounts: https://github.com/opencontainers/runtime-spec  ",
    "sig": "169a62d1a68bbcb1d674861cee3765ca5aa772f185cff4f234913250f42093993c6e2c92be0ec319806aeafc841422398fed61e68160a8e15c8f5ef9c1ae95b1"
}