Archive for the 'Ubuntu' Category

eCryptfs Fehler und seine Ursache

Raphael Vullriede June 8th, 2010

Seit einigen Tagen ist mir folgender Fehler in dmesg aufgefallen:

Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Heute bin ich endlich dazu gekommen, dem Ganzen auf den Grund zu gehen.
Wer nach der Fehlermeldung googelt, findet viele Fälle mit dem gleichen Problem, wie es zu dem Verhalten kommt, scheint aber bei den wenigsten klar zu sein.

Wie kommt es also zu dem Fehler?

Im Gegensatz zu TrueCrypt oder LUKS arbeitet eCryptfs auf Dateiebene, d.h., es werden keine logische Blöcke verschlüsselt, sondern der Inhalt der Datei. Außerdem werden alle notwendigen META-Informationen im Dateikopf abgelegt, sodass außer der Datei keine weiteren Informationen notwendig sind. Das vereinfacht z.B. den Transfer zu anderen Partitionen/Rechnern/Online-Backup erheblich.
Die oben genannte Fehlermeldung scheint nun immer dann aufzutreten, wenn 0-Byte-Dateien in dem eCryptFS-Verzeichnis existieren. Dies darf nie passieren, da selbst bei der Anlage einer leeren Datei wenigstens die META-Informationen im Kopf gespeichert werden müssen. Das kann man sehr leicht nachvollziehen:

Anlage einer leeren Datei im Home-Verzeichnis:

rv@dragonwing:~$ cd
rv@dragonwing:~$ touch ecryptfsTest
rv@dragonwing:~$ ll ecryptfsTest
-rw-r--r-- 1 rv rv 0 2010-06-08 17:11 ecryptfsTest
rv@dragonwing:~$ ls -ltr .Private/ | tail -n 1
-rw-r--r--  1 rv rv   12288 2010-06-08 17:11 ECRYPTFS_FNEK_ENCRYPTED.FWaJYa64rxF88kRDJ3jNxY2hIlwDcigV0J4HVk8Iaq8OE8IcE-EL4NPpak--

Man sieht also, dass diese leere Original-Datei verschlüsselt eine Größe von 12288 Bytes hat. Falls eCryptFS also auf eine leere Datei stößt, meckert es zu Recht die fehlenden META-Informationen an.

Wie kann es nun zu den 0-Byte-Dateien kommen?

Dafür gibt es eine ganze Reihe von möglichen Gründen: Programmabstürze beim Speichern einer Datei, ein alter Ext4-Bug oder wie in meinen Fall eine randvolle Partition ;-) Der notwendige Platz stand einfach mehr zur Verfügung. Ich bin allerding der Meinung eCryptFs sollte dieses im Vorfeld überprüfen, zumal das aus anscheinend relativ häufig vorkommt.

Wie wird man diese Dateien wieder los?

find $HOME/.Private/ -xdev -size 0c

findet die Dateien. Falls sie zur Zeit nicht im Zugriff sind kann man sie gefahrlos löschen, z.B. so:

for i in `find $HOME/.Private/ -xdev -size 0c`; do
  if ! fuser -v $i; then
    rm -f $i
  fi
done

Danach kann man das Log mit

sudo dmesg -c

leeren und sollte wieder Ruhe haben.

Pidgin als Client für den Facebook-Chat

Raphael Vullriede June 7th, 2010

Wer wie ich Pidgin für ICQ/MSN/Sametime etc. benutzt, sollte sich mal http://www.facebook.com/sitetour/chat.php anschauen. Da Facebook für den Chat XMPP benutzt, ist man nicht mehr auf den grottigen Javascript-Chat angewiesen, sondern kann das Lieblingsprogramm seiner Wahl benutzen.

Duden Korrektor unter Ubuntu OpenOffice 3.2

Raphael Vullriede June 2nd, 2010

Wer wir ich in OpenOffice gerne mit einer besseren Rechtschreibkontrolle arbeitet, ist zur Zeit auf das Produkt Korrektor von DUDEN angewiesen. Dieses ist in der aktuellen Version 6 auch für Linux verfügbar. Die OpenOffice-Erweiterung ist laut Beschreibung ab OpenOffice Version 3.1 lauffähig.
Wer aber z.B. die vorinstallierte OpenOffice-Version 3.2 von Ubuntu (in meinem Fall 10.04) benutzt, wird bei der Installation der Erweiterung auf folgende Fehlermeldung stoßen:

(com.sun.star.registry.CannotRegisterImplementationException)
{ { Message=”", Contex= (com.sun.star.uno.Xinterface) @0 } }

Abhilfe schafft hier die Installlation des Pakets openoffice.org-java-common, welches bei der Ubuntu-Standardinstallation seltsamerweise fehlt.

sudo apt-get install openoffice.org-java-common

Festplatten-Verschlüsselung unter Linux/Ubuntu

Raphael Vullriede November 21st, 2009

Anlässlich des Kaufes einer externen Festplatte für mein Notebook (Plextor PX-PH500US) habe ich die Gelegenheit genutzt, mir mal die Performance verschiedener Verschlüsselungsmöglichkeiten unter Linux anzuschauen. Da eine für den Nutzer transparente Verschlüsselung des Home-Verzeichnisses möglich sein sollte, blieben nur eCryptfs und LUKS. Zusätzlich habe ich noch TrueCrypt getestet, da ich das bereits unter Windows genutzt habe.
eCryptfs und LUKS/Truecrypt benutzen unterschiedliche Ansätze wie Dateien verschlüsselt werden. Während eCryptfs tatsächlich einzelne Dateien verschlüsselt, operieren LUKS/Truecrypt auf Blocklevel. Zu Vor- und Nachteilen einfach mal Google bemühen.

Testsystem:

uname -a
Linux nexus 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686 GNU/Linux
cat /proc/cpuinfo | grep "model name"
model name    : Intel(R) Core(TM)2 Extreme CPU Q9300  @ 2.53GHz
model name    : Intel(R) Core(TM)2 Extreme CPU Q9300  @ 2.53GHz
model name    : Intel(R) Core(TM)2 Extreme CPU Q9300  @ 2.53GHz
model name    : Intel(R) Core(TM)2 Extreme CPU Q9300  @ 2.53GHz
sudo hdparm -I /dev/sdb | grep Model
Model Number:       TOSHIBA MK5055GSX

Interessant, Plextor verbaut also Toshiba-Platten…

Um die Test einfach zu halten benutze ich Bonnie 1.03c . Es gibt sicherlich bessere Benchmarks aber um einen ersten Eindruck zu bekommen reicht es! Bei der Interpretation beziehe ich mich in erster Linie auf die Block-Operationen, da diese in einem echten System den Großteil des Workload ausmachen.

Zum Vergleich erstmal die Performance ohne Verschlüsselung im Auslieferungszustand, d.h. VFAT als Dateisystem:

VFAT USB 2.0

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bl018550         6G 28284  56 28552   7 14808   5 33960  75 34282   5 143.8   0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
16    75  64 +++++ +++  1826  99   107  50 +++++ +++   665  96

VFAT eSATA

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bl018550         6G 49123  76 60099  12 30173   9 72605  94 75029  11 164.4   0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
16    86  63 +++++ +++  1834  99   114  51 +++++ +++   675  98

Wie nicht anders zu erwarten ist eSATA in allen Bereichen um Längen besser. Interessant dabei ist allerdings die höhere CPU-Auslastung. Alle weiteren Tests wurden nur noch mit eSATA durchgeführt.

Alles erstes mal ein vernünftiges Dateisystem testen:

Ext4 eSATA

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bl018550         6G 53860  80 54020  10 25841   6 67645  92 73386  11 174.7   0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

53,8MB/s schreiben und 73,4MB/s lesen, nicht schlecht! Auf jeden Fall besser als meine interne Festplatte :-)

Zuerst zum Vergleich eCryptfs:

Ext4 eCryptFS eSATA

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bl018550         6G 29381  97 48973  97 21543  57 46309  97 73448  71 112.2   1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
16  4846  52 +++++ +++ 25089  89  9856  96 +++++ +++  4622  13

Es bleiben 48,9MB/s schreiben und 73,4MB/s lesen bei deutlich höherer CPU-Auslastung. Weiterhin sind die Seeks/s deutlich zurückgegangen. Der Performance-Verlust ist allerdings nicht so hoch wie erwartet.

Ext4 LUKS (aes-xts-plain, 256Bit, cryptsetup 1.0.6)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bl018550         6G 51435  77 49828   8 27971   7 52273  76 73933  10 167.7   0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

49,8MB/s schreiben, 73,9MB/s lesen. Die Werte sind somit nahezu gleich zu eCryptfs, trotz vollkommen unterschiedlicher Ansätze. Allerdings ist die CPU-Auslastung gerade mein Lesen deutlich geringer und es sind mehr Seeks möglich.

Ext4 TrueCrypt eSATA (AES 128Bit, RIPE-160, TrueCrypt 6.3)
Da der TrueCrypt-Wizard auch in der aktuelle Version noch kein Ext4 kennt musste ich das Dateisystem von Hand anlegen, wie zu Beispiel hier beschrieben.

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bl018550         6G 50909  84 52487   8 27557   6 41492  85 74252  12 174.3   0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

52,4MB/s schreiben und 74,2MB/s lesen. Schreiben und Seeks/s sind hier also fast genauso schnell wie ohne Verschlüsselung.

Fazit:

  • Verschlüsselung muss kein Performancefresser sein (Vorausgesetzt man hat eine CPU dafür über ;-) )
  • Schreiboperationen sind bei allen Lösungen zwar langsamer als ohne Verschlüsselung, ob der Unterschied in der Praxis allerdings eine Rolle spielt sei dahingestellt.
  • eCryptfs hat leichte Nachteile gegenüber Mechanismen die auf Blocklevel-Ebene arbeiten. Dafür ist die Integration in Ubuntu deutlich besser und man kann die verschlüsselten Dateien einfacher sichern.