Userspace-Dateisysteme führen das Unix-Paradigma "Alles ist eine Datei" konsequent fort. Sie verwandeln Datenbanken, SSH-Verbindungen oder E-Mail-Accounts in Dateien. Für die Verschlüsselung lokaler Dateien ist ebenfalls gesorgt. So ersparen sich Anwender das Aufsetzen komplizierter Clients.

Es scheint ein Wesenszug von Computerdaten zu sein, möglichst verstreut aufzutreten: In Datenbanken, auf Fileservern, in Mailboxen oder auf Chipkarten. Und für jedes dieser Speichermedien gibt es extra Software, mit der die User auf ihre Daten zugreifen müssen. Wünschenswert wäre eine einheitliche Schnittstelle zu allen Informationen. Die hier vorgestellten Userspace-Dateisysteme leisten genau dies. Sie stellen Anwendern Daten aus den verschiedensten Quellen im Dateisystem bereit. So reduziert sich die Aufgabe, Informationen von der lokalen Chipkarte zum Computer am anderen Ende der Welt zu schicken, auf den einfachen Aufruf »cp QuelldateiZielverzeichnis«.

Obwohl sich die zahlreichen Implementierungen im Detail unterscheiden, ist das Prinzip der Userspace-Dateisysteme stets gleich. Ein Kernelmodul hängt sich in das virtuelle Filesystem (VFS) des Kernels ein und fängt Systemaufrufe wie »open()«, »read()« und »write()« ab. Diese leitet es an einen Daemon oder eine Bibliothek weiter. Die kümmern sich dann um die Ausführung des Aufrufs, etwa bei einem »read()« den entsprechenden Befehl über das SSH-Protokoll an den entfernten Rechner zu schicken. Abbildung 1 illustriert diese Funktionsweise anhand von SHFS[1], das eine SSH-Verbindung ins Dateisystem einbindet. Dank des VFS bemerken die Anwendungen gar nicht, aus welcher Quelle die Dateien kommen.

Abbildung 1: Über ein Kernelmodul erhalten Userspace-Filesysteme den Zugriff auf die Systemaufrufe. Das VFS erlaubt die verschiedensten Kombinationen. ProcFS etwa stellt Systeminformationen bereit und NFS beliefert den Anwender mit Daten aus dem Netzwerk.

Vorteil Userspace

Theoretisch wäre es auch möglich, alle Funktionen direkt in den Kernel zu integrieren. Doch es ist sinnvoller, nur den unabdingbaren Teil der Programmlogik in ein Kernelmodul zu packen. Im Userspace nutzen die Programmierer dann die schon vorhandenen Bibliotheken und Programme. Den Großteil der Logik in den Userspace zu verlagern, eröffnet den Programmierern somit schier unendliche Möglichkeiten.

Mit den beiden Frameworks Fuse[2] und Lufs[3] lassen sich relativ einfach neue Dateisysteme entwickeln. Sie enthalten beide ein Kernelmodul und stellen für es Interfaces bereit. Bei Fuse erstellt der Programmierer ein eigenes Binary, das sich um das Mounten kümmert, in Lufs gibt es das generische Programm »lufsmount«, das eine jeweils passende Shared Library zur Laufzeit einbindet.

Fuse-Framework

Da die meisten Distributoren (außer Debian) keine Fuse-Pakete ausliefern, müssen Anwender die Sourcen von der Website[2] selbst kompilieren. Das geht aber problemlos vonstatten. (Trotz einer Fehlermeldung wie »failed to set capabilities: Operation not permitted« beim Mounten von Fuse-Filesystemen funktioniert das System.) Die Fuse-Suite kommt lediglich mit einem kleinen Beispielprogramm. Eine Liste aller Dateisysteme gibt es auf[4].

Eines davon ist EncFS[5], das Dateien transparent on the fly verschlüsselt. Es benutzt die OpenSSL-Bibliothek und ist einfach zu handhaben. Nach der Installation genügt der Aufruf »encfs QuellverzeichnisZielverzeichnis«. Alle Dateien, die Anwender nun im Verzeichnis Zielverzeichnis anlegen, verschlüsselt EncFS. Die geschützten Dateiversionen landen im Quellverzeichnis. Nach dem Unmounten verschwinden die Dateien aus Zielverzeichnis wieder . In Listing 1 ist eine Beispielsession dargestellt.

01 murdoc:/home/mwerner/crypt/encfs$ encfs ~mwerner/crypt/encfs/raw/ ~mwerner/crypt/encfs/work/
02 EncFS Password:
03 murdoc:/home/mwerner/crypt/encfs$ ls work/
04 bar  foo  hello  test1  test2
05 murdoc:/home/mwerner/crypt/encfs$ touch work/diesisteintestencfsisttoll
06 murdoc:/home/mwerner/crypt/encfs$ fusermount -u ~mwerner/crypt/encfs/work/
07 murdoc:/home/mwerner/crypt/encfs$ ls raw/
08 BrzSPmfOyQShlXuiqnK,pTGE  Iqhy2xMtpIgZySpATSWqW8Tq  tSjZO5MKdWKAyinOnicF5amoHFLeHLAAF64usx69QsNm70
09 C5PWTazUPXqZ7A4bO5RyVm2A  m02yh6RPu8g6kw6W-DcSfTDC
10 D8A8qec=                  saoS-CJfXj2Gr,Q,ATWGPnTS
11 murdoc:/home/mwerner/crypt/encfs$

EncFS arbeitet also ähnlich wie die Kernelspace-Implementationen (DM-Crypt, Cryptoloop, Loop-AES). Doch da es im Userspace arbeitet, ist es flexibler: In den oben genannten Kernel-Crypto-Filesystemen müssen Anwender ein Dateisystem mit einer festen Größe anlegen, das sich nicht vergrößern oder verkleinern lässt. Da EncFS auf Verzeichnisebene arbeitet, ist die Größe lediglich durch die Partition bestimmt, auf der das verschlüsselte Verzeichnis liegt. Außerdem gestalten sich Backups leichter, da das Backupprogramm das Dateisystem nicht mounten muss, sondern einfach die verschlüsselten Dateien kopiert.

Angreifern ist es allerdings möglich, die Anzahl, Größe oder Rechte der verschlüsselten Dateien zu sehen. Daher ist EncFS nicht ganz so sicher wie seine Kernel-basierten Kollegen. Im Test wollte es außerdem nicht mit regulären Benutzern zusammenarbeiten, daher war es nötig, als Root zu mounten und die Rechte entsprechend zu setzen.

Gmail mal anders

Das Dateisystem GmailFS[6] beruht ebenfalls auf Fuse. Es missbraucht den Mailbox-Speicherplatz des Webmail-Dienstes Google Mail als Datenspeicher. Das Webmail-Angebot von Google ist seit seiner Ankündigung im April 2004 heftig umstritten, da der Anbieter die E-Mails der Benutzer nach Stichwörtern durchsucht und kontextbezogene Werbung einblendet.

Wer seine E-Mails daher lieber auf der heimischen Festplatte lagert, hat mit GmailFS die Möglichkeit, seinen Account anderweitig zu nutzen. Denn Google stellt jedem Anwender 1 GByte Speicher zur Verfügung, was für so manche Fotosammlung ausreichen sollte. (Eine Kombination von GmailFS und EncFS hat in einem Test der Linux-Magazin-Redaktion leider nicht funktioniert.)

Die Installation des Gmail-Dateisystems ist etwas aufwändiger. Das Programm ist in Python geschrieben und benötigt daher die Fuse-Python-Bindings. Außerdem müssen Anwender die Libgmail[6] installieren. Auf derselben Homepage ist die Installation detailliert beschrieben. Debianer sind im Vorteil, für sie gibt es alle Pakete mit der Distribution.

GmailFS speichert Dateien inklusive ihrer Metadaten als E-Mails auf dem Account des Benutzers. Die Daten selber steckt es in Attachments. Die Performance dieses ungewöhnlichen Dateisystems ist noch erträglich – bleibt lediglich die eher moralische Frage, ob man einen kostenlosen E-Mail-Dienst als Festplatte missbrauchen sollte.

Für alle, die sich mit dem Gmail-Dienst auseinandersetzen wollen, findet mit Erscheinen dieser Linux-Magazin-Ausgabe auf [http://www.linux-community.de] eine Diskussion über Nutzen und Gefahren dieses Angebots statt.

SSH, die Erste

Das zweite Userspace-Filesystem-Framework Lufs enthält bereits eine Reihe von Implementationen. Es reicht also, sich das Archiv von[3] herunterzuladen und mit »./configure && make && make install« zu installieren. Allerdings sträubte sich beim Test mit Linux 2.6 »make install« das Kernelmodul an die richtige Stelle zu setzen. Daher ist es erforderlich, die Datei »kernel/Linux/2.6/lufs .ko« von Hand nach »/lib/modules/ Kernelversion/kernel/fs/lufs/« zu kopieren. Nach dem Laden des Moduls mounten Anwender die Dateisysteme mit dem Programm »lufsmount«.

Ein Vorteil von Lufs ist der einheitliche Aufruf beim Mounten mit »lufsmount«. Das Programm erwartet als Parameter den Dateisystemtyp in der Form Filesystem:// sowie einen Hostnamen und den Mountpoint. Herz von Lufs ist der »lufsd«, ein Daemon, der die Shared Library des gewünschten Dateisystems im Betrieb nachlädt. Er startet automatisch beim Aufruf von »lufsmount«.

Das bekannteste unter den Lufs-Dateisystemen ist SSHFS. Es stellt den Verzeichnisbaum entfernter Rechner im lokalen System dar. Dabei verläuft der komplette Datenverkehr mit SSH verschlüsselt. Die Übertragungsrate ist allerdings geringer als bei einer normalen SSH-Verbindung. Daher benutzt SSHFS einen Cache, der sich wiederholende Aktionen recht zuverlässig beschleunigt.

Die Leseoperationen sind zwar relativ schnell, doch dauert das Kopieren von Dateien innerhalb der gemounteten Verzeichnisse extrem lange. SSHFS kopiert nämlich die Daten zuerst auf den lokalen Rechner und dann wieder zurück.

SSHFS hat in einigen Situationen Probleme damit, die Rechte von Dateien richtig zu setzen. User können dann unter Umständen einige Dateien vom SSH-Server nicht lesen. Auch die Mount-Optionen »fmode« und »dmode« zum Setzen der Datei- und Verzeichnisrechte schaffen keine Abhilfe.

CryptoFS

Das Pendant zu EncFS heißt bei Lufs CryptoFS[7], ist aber nicht in der Suite enthalten. Zur Verschlüsselung der Daten benutzt CryptoFS die Bibliothek Libgcrypt. Im Gegensatz zu EncFS lässt sich dieses Dateisystem auch von normalen Benutzern mounten, wenn das SUID-Bit von »lufsmount« gesetzt ist. Um ein Verzeichnis mit CryptoFS zu mounten, müssen Anwender zuerst die Datei »cryptofs.conf« aus den Sourcen des Pakets in ».cryptofs« umbenennen und in jenes Verzeichnis kopieren, das später die verschlüsselten Dateien enthalten soll.

Ein »lufsmount cryptofs:// QuellverzeichnisZielverzeichnis« mountet es dann. Dabei legt der Benutzer ein Passwort fest, das später bei jedem Mount abgefragt wird. Auch CryptoFS verschlüsselt nicht nur die Daten, sondern auch die Dateinamen. Die Sicherheitsprobleme von EncFS bestehen hier ebenfalls.

SSH, die Zweite

Um lediglich entfernte Verzeichnisse per SSH zu mounten, ist es nicht erforderlich, eine komplette Umgebung wie Fuse oder Lufs zu installieren. Das Dateisystem SHFS von[8] gleicht grundsätzlich dem SSHFS aus Lufs. Allerdings ist diese Implementation stabiler. Mit SHFS treten jedoch die Rechteprobleme von SSHFS nicht auf.

Nichts ist unmöglich

Wie oben erwähnt sind den Userspace-Dateisystemen kaum Grenzen gesetzt. Run-Time Access[9] etwa liest die internen Strukturen laufender Prozesse aus und speichert Variablen in einer Datenbank. Per Fuse greifen Anwender übers Dateisystem darauf zu.

RelFS, ebenfalls ein Fuse-Modul, speichert hingegen Metadaten von Dateien und Verzeichnissen in einer PostgreSQL-Datenbank. Mit Plugins lässt sich so ein Datenbestand erstellen, der etwa zu MP3-Dateien Titel und Interpreten speichert oder zu Fotos Personennamen und den Ort der Aufnahme.

Wer sein System nicht mit zusätzlichen Kernelmodulen vollpfropfen will, benutzt Gnome oder KDE, sie besitzen ebenfalls Bindings zu vielen Protokollen. Im Gegensatz zu Fuse und Lufs laufen sie ausschließlich im Userspace. Um beispielsweise in KDE ein Samba-Share (siehe Abbildung 2 sowie den SMB-Artikel in dieser Ausgabe) einzubinden, genügt bereits die Eingabe von »smb:// Servername/ Share« in der Titelleiste des Konqueror. Für den Rest sorgt ein so genannter KIO-Slave. Der Konsolen-Dateimanager Midnight Commander enthält wie KDE das Fish-Protokoll (Abbildung 2), das eine SSH-Verbindung für den Dateitransfer benutzt.

Abbildung 2: Auf der Konsole sorgt der Midnight Commander für komfortable Anbindung. Wie die KDE-Umgebung auch benutzt der Commander das Fish-Protokoll für SSH-Verbindungen.

Abbildung 3: KDE besitzt mit seinen KIO-Slaves auch einige Userspace-Dateisysteme. Hier zeigt der Konqueror ein Verzeichnis, das über Samba gemountet ist. Weitere Slaves gibt es für SSH, Bluetooth oder Digitalkameras.

Fazit

Für Desktop-Anwender gibt es sehr viele Möglichkeiten, ihre Daten über das Dateisystem auszutauschen. Leider befinden sich alle vorgestellten Userspace-Dateisysteme noch in der Entwicklung und sind daher oft instabil. Wer seine Daten möglichst zuverlässig und sicher verwalten muss, sollte eher bei traditionellen Systemen bleiben.