Pass-Through-Methode auf Kernel-Ebene zum Ändern von Dateihashes

352
Hamy

Ich suche nach Mechanismen auf Kernel-Ebene, bei denen es sich um Pass-Through handelt und die Hashes der Datei ändern, indem sie entweder den Dateiinhalt verschlüsseln oder Daten anfügen. Die naheliegendste Lösung ist die Verschlüsselung, aber ich kann keine geeigneten Verschlüsselungsmethoden (z. B. nur Kernel, keine Ecryptfs, keine FUSE-Unterstützung usw.) finden.

Im Besonderen habe ich eine große Anzahl von Dateien, in /foodenen ich auch so erscheinen möchte /foobar, dass das Original-MD5 der Dateien verschleiert wird, ohne die Rohdaten zu duplizieren. Ich mache mir keine Sorgen, wenn die Dateien /foobardurch Zusätze unbrauchbar werden. Ich freue mich, ein paar zufällige Bytes an jede Datei anhängen zu können, und das lässt viele Dateiformate kaputt gehen, aber ich weiß nicht, wie man das mit einigen macht eine Art Bind-Mount

0

1 Antwort auf die Frage

1
grawity

Wenn Sie nach einem benutzerdefinierten Dateisystem-Overlay suchen, ist FUSE die richtige Richtung. Es gibt verschiedene benutzerdefinierte Dateisysteme, die mit FUSE geschrieben wurden (sshfs, ntfs-3g, wikipediafs ...), einschließlich einfacher Überlagerungen wie bindfs .

Man könnte den bindfs-Quellcode nehmen und ihn modifizieren, um zum Beispiel XOR das erste Byte mit einigen zufälligen Daten zu ändern, wenn er eine Leseoperation verarbeitet.

Bei einer reinen Kerneloption können Sie overlayfsoder unionfsTreiber auf ähnliche Weise ändern .

Eine andere Alternative ist, Samba zu nehmen, ein Samba-VFS-Modul zu schreiben, um Dateien zu beschädigen, das Quellverzeichnis freizugeben und es auf demselben Computer mit dem Linux- cifsTreiber bereitzustellen . (Das Gleiche ist auch mit dem 9pTreiber und dem u9fsDaemon oder mit dem nfsTreiber und einem anderen NFS-Server-Daemon möglich.)


Wenn Sie sich nicht für den Inhalt interessieren, erstellen Sie spärliche Dateien mit der gewünschten Größe. Sie nehmen überhaupt keinen Platz ein:

$ truncate -s 1G largefile $ du -h --apparent largefile 1G largefile $ du -h largefile 0 largefile 

Schleife über einen Baum wie folgt:

cd /foo find -type d | while read -r file; do mkdir -p "/foobar/$file" done find -type f | while read -r file; do truncate -r "$file" "/foobar/$file" done 
Ich brauche einen Mechanismus auf Kernel-Ebene, der die Verwendung von FUSE ausschließt: - / Ansonsten wäre das toll :-P Hamy vor 9 Jahren 0
Oh, spärliche Dateien sind eine großartige Idee, aber ich sollte klarstellen, dass es mir wichtig ist, dass der Inhalt erhalten bleibt. Ich möchte nur, dass der Hash anders ist. Ich werde meinen Beitrag aktualisieren, entschuldige die Verwirrung Hamy vor 9 Jahren 0
@Hamy: Könnten Sie auch erklären, warum genau ein Kernel-Mechanismus erforderlich ist und warum FUSE unbrauchbar wird? grawity vor 9 Jahren 0
Sicher - Nur Kernel ist eine Anforderung von CrashPlan - Er kann Dateien (z. B. verschlüsselte Dateien) anscheinend nicht ordnungsgemäß statisieren, es sei denn, die Änderungen werden im Kernel vorgenommen und sind daher für diesen völlig unsichtbar. Die Kernel-Only-Anforderung entfernt die Möglichkeit, FUSE vollständig zu verwenden, da (AFAIK) jedes einzelne FUSE-basierte Dateisystem im Benutzerbereich ausgeführt wird, während Fuse selbst der Teil ist, der im Kernel ausgeführt wird Hamy vor 9 Jahren 0
Zu Ihrer Information, ich habe noch kein FUSE-basiertes System ausprobiert, aber ich sehe hoffnungsvolle Berichte, dass sshfs mit crashplan tatsächlich unter http://askubuntu.com/questions/337305/back-up-sshfs-network-drive-to verwendet werden kann -crashplan, also versuche ich es jetzt. Vielleicht war die Antwort die ganze Zeit offensichtlich ... * Daumen drücken * Hamy vor 9 Jahren 0
@Hamy: Der FUSE-Controller befindet sich im Benutzerbereich, der Dateisystemtreiber befindet sich jedoch im Kernel. Wenn der Controller die erforderlichen Funktionen implementiert, ist er _indistinguishable_ von jedem anderen Dateisystem für alle anderen User-Space-Programme. Und wie der Beitrag von Ask Ubuntu zeigt, liegt das Problem nicht in FUSE, sondern in FUSE, die standardmäßig anderen Benutzern als dem Mounter den Zugriff verweigert ("-o allow_other"). grawity vor 9 Jahren 0
Sie haben Recht, ich habe falsch verstanden, was CrashPlan mit "nur Kernel" meinte, wenn ecryptfs nicht sofort funktionierte. Ich habe gerade ein auf FUSE basierendes Dateisystem getestet und es hat perfekt funktioniert. Vielen Dank, dass Sie mir einen zweiten Blick auf FUSE gegeben haben! Hamy vor 9 Jahren 0