☰

Vortäuschen eines Verzeichnispfads, ohne dass der vollständige Pfad vorhanden ist

tag-icon • tag-icon mount directory symlink
Vortäuschen eines Verzeichnispfads, ohne dass der vollständige Pfad vorhanden ist

Ich arbeite mit einem Build-System, das auf absoluten Pfaden basiert, um Quelldateien usw. zu referenzieren. Wenn ich das Erstellen mit verschiedenen Toolchains testen möchte, mounte ich das src-Verzeichnis in VMs oder Chroots. Das Problem ist, dass der Pfad zu meinem src-Verzeichnis auf meinem Host-Rechner sehr komplex ist – sagen wir /a/b/c/d/src – und er muss mit dem gemounteten Pfad übereinstimmen.

Ich möchte mein src-Verzeichnis an einem Ort wie /mnt/src mounten können, muss dazu aber immer einen symbolischen Link von /a/b/c/d/src zu /mnt/src erstellen oder den Mountpoint direkt bei /a/b/c/d/src haben.

Es fühlt sich schmutzig an, /a/b/c/d im Dateisystem zu haben, und im Allgemeinen haben Sie möglicherweise nicht einmal die Berechtigung, Dateien in /a/b/c/d (oder einem der übergeordneten Verzeichnisse) zu erstellen. Gibt es eine Möglichkeit, diesen Pfad zu fälschen, um mein Build-System zu besänftigen?

Antwort1

Die beste Lösung wäre, dem Build-System beizubringen, dass Quellpfade und Installationspfade nicht dasselbe sind, aber ich gehe davon aus, dass das nicht möglich ist.

Die einfachste Methode wäre, den Quellpfad so einzurichten, dass er leicht reproduziert werden kann, wie z . B. /var/tmp/mybuild. Wenn das Build-System nicht zu aufdringlich ist, sollte es ausreichen, einen symbolischen Link zum Speicherort der Dateien zu erstellen. Wenn das Build-System darauf besteht, symbolische Links zu kanonisieren, sollten Sie es austricksen können, indem Sie einenBind-Mountstattdessen. Mit bindfs benötigen Sie keine Root-Rechte, Sie müssen nur über Schreibberechtigung für den Speicherort verfügen, an dem die Dateien angezeigt werden sollen.

Wenn Sie nicht auf das Quellsystem einwirken können, besteht ein alternativer Ansatz darin,Laden Sie eine dynamische Bibliothek vor, die bestimmte Dateizugriffe umleitet. Dies setzt voraus, dass alle ausführbaren Dateien, die ausgeführt werden, dynamisch verknüpft sind. Der Code im verlinkten Beispiel zeigt, wie dies von einer bestimmten Datei aus gemacht wird; er kann so angepasst werden, dass alle Dateien umgeleitet werden, deren Pfad mit einem bestimmten Präfix beginnt. Ersetzen Sie

if (!strcmp(path, FROM)) {
    path = TO;
}
…
return ret;

durch etwas wie (ungetestet)

char *other_path = NULL;
if (!strncmp(path, FROM, strlen(FROM))) {
    other_path = malloc(strlen(path) - strlen(FROM) + strlen(TO) + 1);
    if (other_path == NULL) return -ENOENT; // return NULL in fopen
    memcpy(other_path, TO, strlen(TO));
    memcpy(other_path + strlen(TO), path + strlen(FROM), strlen(path) - strlen(FROM) + 1);
    path = other_path;
}
…
free(other_path);
return ret;

Antwort2

Wenn Sie vermeiden möchten, dass „der Host“ mit Rückständen von Test-Builds verunreinigt wird, firejailist das Erstellen innerhalb eines persistenten Overlays eine gute Option. Bei diesem Ansatz würde es wie in echt erstellt und möglicherweise installiert, aber die Dateien landen in einem Overlay, anstatt „das echte“ Dateisystem zu verunreinigen.

Dies hat den Nachteil, dass Sie die Testbuild-Ergebnisse innerhalb des Overlays suchen müssen. Gleichzeitig bietet es jedoch möglicherweise den Vorteil, dass nachfolgende Testbuild-Ergebnisse erhalten bleiben, z. B. um sie zu vergleichen oder für andere spätere forensische Untersuchungen, die Sie möglicherweise durchführen müssen.

verwandte Informationen