eCryptfs with dropbox: muss erneut bereitgestellt werden, damit synchronisierte Änderungen sichtbar werden

3315
Quantumboredom

Ich experimentiere mit der Verwendung von eCryptfs auf Dropbox, und ich stoße auf einige Probleme.

Mein System ist GNU / Linux, openSUSE 12.2, um genau zu sein.

Mein Setup ist folgendermaßen: Ich habe zwei Instanzen von VirtualBox eingerichtet, auf denen openSUSE 12.2 ausgeführt wird. Wir nennen sie VM1 und VM2. Dropbox synchronisiert wie üblich alles in ~ / Dropbox. Um mein eCryptfs-Setup zu erstellen, mache ich auf beiden VMs Folgendes:

mkdir -m 500 ~/ecryptfs_upper mkdir -m 700 ~/Dropbox/ecryptfs_lower sudo mount -t ecryptfs Dropbox/ecryptfs_lower/ ecryptfs_upper/

Ich konfiguriere eCryptfs mit:

key type: passphrase cipher: aes key bytes: 16 plaintext passthrough: no filename encryption: yes

Wenn ich jetzt mit dem Erstellen einer Datei in ~ / ecryptfs_upper auf VM1 fortfahre, wird sie auch auf VM2 korrekt angezeigt. Wenn ich diese Datei dann auf einer VM ändere, wird sie manchmal (oft, jedoch nicht immer aus irgendeinem Grund) auf der anderen VM nicht aktualisiert.

Wenn ich die zugrunde liegenden Dateien in ~ / Dropbox / ecryptfs_lower auf den beiden VMs inspiziere, sind sie identisch (sha256sum erzeugt denselben Hash). Dropbox hat es also richtig geschafft, sie zu synchronisieren. Die entsprechenden Dateien in ~ / ecryptfs_upper sind jedoch immer noch unterschiedlich! Ich muss dann eCryptfs wieder mounten, damit die Änderungen korrekt angezeigt werden.

Das Problem scheint zu sein, dass, wenn dropbox eine Datei im unteren Verzeichnis von eCryptfs aktualisiert, eCryptfs die Änderung nicht bemerkt. Vermutlich geht eCryptfs davon aus, dass alle Änderungen den Mount durchlaufen. Für die meisten Anwendungsfälle ist dies natürlich eine vernünftige Annahme, aber wenn Sie eCryptfs verwenden, um synchronisierte Cloud-Speicher wie Dropbox zu verschlüsseln, ist dies offensichtlich ein großes Problem.

Ich habe mehrere Leute gesehen, die sich für die Verwendung von eCryptfs mit Dropbox ausgesprochen haben, aber dieses Problem wurde nicht erwähnt. Kennt jemand einen Fix (eine Möglichkeit zum Deaktivieren des Cache, den eCryptfs zum Beispiel verwendet) oder eine Alternative zu eCryptfs, die nicht unter diesem Problem leiden würde?

4

3 Antworten auf die Frage

3
hrunting

Look at encfs as an alternative to eCryptfs. It does not suffer from the problem you describe.

EncFS/Dropbox setup tutorial

EncFS scheint in der Tat nicht unter diesem Problem zu leiden, was es für diese Aufgabe viel geeigneter macht. Ich habe auch https://github.com/timoc/encfsbox gefunden, das der Dropbox + EncFS-Kombination einen netten Konfliktbehandlungsmechanismus bietet, der es zu einer sehr schönen Lösung macht. Quantumboredom vor 11 Jahren 2
Unter Windows, Mac und Mobile können Sie [BoxCryptor] (https://www.boxcryptor.com/) verwenden, um den Zugriff auf die verschlüsselten Daten zu erleichtern. hrunting vor 11 Jahren 1
Beachten Sie die kryptografischen Schwachstellen in EncFS, wenn Sie sich bei kritischen Problemen darauf verlassen (https://defuse.ca/audits/encfs.htm). An einer 2.0-Version, die diese ansprechen kann oder nicht, wird derzeit gearbeitet, aber noch keine Veröffentlichungen. darrend vor 9 Jahren 1
3
Mike Halcrow

Sie sind über einen Designfehler in eCryptfs unter Linux gestolpert. Es gibt keinen Mechanismus, um eCryptfs mitzuteilen, dass eine Änderung im unteren Seitencache vorgenommen wurde. Daher kann es nicht wissen, ob eine Seite unter diesem Bereich geändert wurde. Das Ändern der niedriger verschlüsselten Dateien auf einem aktiven eCryptfs-Mount ist eine Art Umdrehen von Bits auf dem Blockgerät, während EXT4 angehängt ist. EXT4 hat eine eigene Vorstellung über den Zustand des Blockgerätes, da davon ausgegangen wird, dass es das einzige ist, was mit dem Blockgerät durcheinander kommt. Wenn sich das Gerät darunter verändert, können die Dinge ziemlich schnell nach Süden gehen.

0
siewa001

Es ist keine Lösung, aber sein Weg. Getestet auf Linux Mint 17 und funktioniert einwandfrei, sollte aber auch auf anderen Linux-Distributionen funktionieren.

#! / bin / bash  export PATH = "/ usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin"  xhome = $   # WIE MAN # # Entfernen Sie die vorherige Installation von Dropbox - alle Verzeichnisse (~ / .dropbox, ~ / .dropbox-dist, ~ / Dropbox) und in der Befehlszeile: # # mkdir -p $ /. mount / dropbox # dd if = / dev / zero von = $ /. mount / dropbox.img bs = 4 KB Anzahl = 2 MB für 8 GB # mkfs.xfs $ /. mount / dropbox.img # für XFS, Sie können jedoch Ihr bevorzugtes FS verwenden, z. EXT4 # mkdir $ / bin # # Setzen Sie dieses Skript in $ / bin # # chmod 0755 $ /bin/dropbox-mount.sh # # Zu / etc / sudoers hinzufügen: # # YourUserName ALL = NOPASSWD: / bin / mount # # Führen Sie dieses Skript aus: $ /bin/dropbox-mount.sh # # chown (id -u) :( id -g) $ /. mount / dropbox # # Starten Sie die Dropbox-App und wählen Sie als Basisverzeichnis $ /. Mount / dropbox / aus. # Dropbox erstellt automatisch $ /. Mount / dropbox / Dropbox. # # WICHTIG # Deaktivieren Sie den automatischen Start von Dropbox in den Dropbox-Einstellungen. # Dieses Skript zum automatischen Systemstart hinzufügen (Einstellung-> Startanwendungen)  xdropbox = ". mount / dropbox" xdropbox_dir = "$ / $ " xdropbox_img = "$ / $ .img"  wenn [`mount | grep -c "$ / $ " `-eq 0]; dann Sudo-Mount -o-Schleife $ $  fi  sleep 10 && dropbox start &> / dev / null  Ausfahrt 0

Verwandte Probleme