udev: Mounten Sie das verschlüsselte Volume nach dem Einfügen des USB-Sticks

3159
miracle2k

Ich habe eine verschlüsselte Partition, die ich automatisch einbinden möchte, wenn ich einen USB-Stick mit dem Schlüssel einsetze, und ich möchte es aushängen (und den Mapper schließen), wenn der Stick entfernt wird. Ich benutze Ubuntu Karmic.

Es scheint ein paar Projekte zu geben, die dies für TrueCrypt versuchen (zum Beispiel http://sourceforge.net/projects/tc-wrapper/ ), aber nichts basierend auf dmcrypt / LUKS. Also dachte ich, ich würde mein Glück versuchen, eine Udev-Regel zu schreiben. Nach vielen frustrierenden Stunden kam ich dazu:

ACTION=="add", SUBSYSTEM=="block", ATTRS=="Flash Disk", ATTRS=="USB2.0", RUN+="/home/michael/trigger-mount.sh encrypted" ACTION=="remove", SUBSYSTEM=="block", ENV=="0204", ENV=="6025", RUN+="/home/michael/trigger-mount.sh encrypted"

Es funktioniert, ist aber nicht schön. Das Problem hierbei ist, dass die erste Regel beim Entfernen nicht übereinstimmt, die zweite Regel beim Hinzufügen nicht.

udevadm monitor --property zeigt das (und ziemlich genau dasselbe bei "add").

UDEV [1264556064.762870] remove /devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host47/target47:0:0/47:0:0:0/block/sde (block) UDEV_LOG=3 ACTION=remove DEVPATH=/devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host47/target47:0:0/47:0:0:0/block/sde SUBSYSTEM=block DEVNAME=/dev/sde DEVTYPE=disk SEQNUM=3512 ID_VENDOR=USB2.0 ID_VENDOR_ENC=USB2.0\x20\x20 ID_VENDOR_ID=0204 ID_MODEL=Flash_Disk ID_MODEL_ENC=Flash\x20Disk\x20\x20\x20\x20\x20\x20 ID_MODEL_ID=6025 ID_REVISION=2.00 ID_SERIAL=USB2.0_Flash_Disk-0:0 ID_TYPE=disk ID_INSTANCE=0:0 ID_BUS=usb ID_USB_INTERFACES=:080650: ID_USB_INTERFACE_NUM=00 ID_USB_DRIVER=usb-storage ID_PATH=pci-0000:00:02.0-usb-0:4:1.0-scsi-0:0:0:0 DKD_MEDIA_AVAILABLE=1 DKD_PRESENTATION_NOPOLICY=0 MAJOR=8 MINOR=64 DEVLINKS=/dev/block/8:64 /dev/disk/by-id/usb-USB2.0_Flash_Disk-0:0 /dev/disk/by-path/pci-0000:00:02.0-usb-0:4:1.0-scsi-0:0:0:0

Dies scheint alle Daten zu enthalten, die in beiden Fällen (Hinzufügen, Entfernen) für beide Regeln erforderlich sind.

Der Vollständigkeit halber ist hier die Ausgabe von udevadm info -a -p /sys/block/sde/:

 looking at device '/devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host48/target48:0:0/48:0:0:0/block/sde': KERNEL=="sde" SUBSYSTEM=="block" DRIVER=="" ATTR=="16" ATTR=="256" ATTR=="1" ATTR=="0" ATTR=="512000" ATTR=="0" ATTR=="53" ATTR==" 16 47 504 510 0 0 0 0 0 380 510"  looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host48/target48:0:0/48:0:0:0': KERNELS=="48:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd" ATTRS=="0" ATTRS=="0" ATTRS=="3" ATTRS=="USB2.0 " ATTRS=="Flash Disk " ATTRS=="2.00" ATTRS=="running" ATTRS=="30" ATTRS=="32" ATTRS=="0x41" ATTRS=="0x41" ATTRS=="0x0" ATTRS=="scsi:t-0x00" ATTRS=="0" ATTRS=="1" ATTRS=="none" ATTRS=="240"  ....

Kann jemand etwas Licht ins Dunkel bringen?

2
Gibt es ein spezielles Problem, das Sie haben, oder ist dies nur eine allgemeine Frage "udev + encrypted fs advice please"? quack quixote vor 14 Jahren 0

1 Antwort auf die Frage

1
quack quixote

Ich habe in einer früheren Antwort einige Informationen über die Verwendung von udev als Automounter geschrieben . es (oder die Ressourcen, mit denen es verknüpft ist) kann etwas Licht für Sie bringen.

Mir ist nicht klar, was genau Ihre Frage ist

  • Separate Regeln zum Hinzufügen und Entfernen: Sie können diese möglicherweise konsolidieren, wenn Sie die ACTION- Übereinstimmung löschen. Dies kann jedoch dazu führen, dass die Regel zu oft ausgelöst wird. Ich denke, es ist besser, jede Regel explizit zu treffen. Oder noch besser (aus Gründen, die im Unmount- Abschnitt unten beschrieben werden), löschen Sie die Regel zum Entfernen ganz.

  • In Bezug auf RUN Aktionen in den udev - Regeln: Die RUN Aktion in Ihrer udev - Regel ausführen muss schnell . Schauen Sie sich das Beispiel an, mit dem ich verlinkt habe. Sie werden sehen, dass es zwei Skripte gibt - uDev ruft eines auf, das das andere ausdreht, um den eigentlichen Mount auszuführen, sodass der erste die Verarbeitungssteuerung zeitnah an uDev zurückgeben kann. Wenn du das schon machst, großartig; Andernfalls sollten Sie Ihre Skripte auf ähnliche Weise anpassen.

  • In Bezug auf Aushänge: ich hatte eine Menge Ärger mit dem auf dem Gerät automatisch die Entfernung Aushang, und ich beschloss schließlich nicht eine verwenden „entfernen“ Regel überhaupt nicht . Stattdessen habe ich ein separates Unmounter-Skript geschrieben, das die Regel "Entfernen" ersetzt .

    Dies liegt daran, dass Sie dem Betriebssystem wirklich so viel Zeit geben sollten, wie es erforderlich ist, um das Gerät zu schließen, bevor Sie es physisch entfernen. Es ist eine Sache, ein Laufwerk mitzunehmen, wenn Sie das Dateisystem schreibgeschützt gemountet haben. Ein vollständiges Schreib-Lese-Dateisystem sollte jedoch nach Möglichkeit sauber entfernt werden. (Dies ist, was die Option "Laufwerk sicher entfernen" in Windows ausführt - dies ist ein Mechanismus, um das Laufwerk abzuhängen, bevor das Gerät physisch vom System entfernt wird.)

    Mit einem regulären Dateisystem konnte ich einige Unmounts mit der syncOption zum Zeitpunkt des Einhängens "richtig" zum Laufen bringen, und umount -l(Lazy Unmounts) beim Unmounten. Die faulen Unmounts geben dem Kernel an, das Dateisystem sofort zu trennen, bereinigen Sie jedoch später Verweise auf das Dateisystem, wenn sie nicht mehr ausgelastet sind. Dies funktioniert zwar, aber die Daten sind nicht so sicher wie das vollständige Deinstallieren, bevor das Gerät entfernt wird.

    Aus den gleichen Gründen kann es schwierig sein, Lazy-Unmounts mit einem verschlüsselten Dateisystem auszuführen. Der Device-Mapper fügt den Standard-Dateisystemproblemen eine weitere Komplexitätsebene hinzu. Mir scheint, dies würde ein verschlüsseltes Dateisystem noch empfindlicher für unreine Abbrüche machen. (Ich bin jedoch nicht besonders mit verschlüsselten FSs vertraut, daher können sie dies möglicherweise tolerieren.)

Hoffentlich gibt dir das ein paar Hinweise. Ehrlich gesagt ist uDev für Automounting-Zwecke praktikabel, aber nicht ideal. Der HalEvt-Daemon oder das neuere DeviceKit wäre wahrscheinlich geeigneter.

Verwandte Probleme