udev: montuje zaszyfrowany wolumin po włożeniu pamięci USB

Mam zaszyfrowaną partycję, którą chciałbym zamontować automatycznie po włożeniu pamięci USB zawierającej klucz i chciałbym ją odmontować (i zamknąć program mapujący) po usunięciu pamięci. Używam Ubuntu Karmic.

Wydaje się, że istnieje kilka projektów, które próbują to zrobić dla TrueCrypt (na przykład http://sourceforge.net/projects/tc-wrapper/ ), ale nic nie opiera się na dmcrypt / LUKS. Pomyślałem więc, że spróbuję szczęścia przy pisaniu reguły udev. Po wielu frustrujących godzinach wymyśliłem:

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

Działa, ale nie jest fajne. Problem polega na tym, że pierwsza zasada nie pasuje podczas usuwania, druga nie pasuje podczas dodawania.

udevadm monitor --property pokazuje to (i prawie to samo w „dodawaniu”).

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

Wydaje się, że zawiera wszystkie dane, które byłyby konieczne do dopasowania obu reguł w obu przypadkach (dodawanie, usuwanie).

Dla kompletności, oto wynik 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{range}=="16"
    ATTR{ext_range}=="256"
    ATTR{removable}=="1"
    ATTR{ro}=="0"
    ATTR{size}=="512000"
    ATTR{alignment_offset}=="0"
    ATTR{capability}=="53"
    ATTR{stat}=="      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{device_blocked}=="0"
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="3"
    ATTRS{vendor}=="USB2.0  "
    ATTRS{model}=="Flash Disk      "
    ATTRS{rev}=="2.00"
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0x41"
    ATTRS{iodone_cnt}=="0x41"
    ATTRS{ioerr_cnt}=="0x0"
    ATTRS{modalias}=="scsi:t-0x00"
    ATTRS{evt_media_change}=="0"
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"
    ATTRS{max_sectors}=="240"

 ....

Czy ktoś może rzucić na to trochę światła?

Napisałem kilka informacji na temat używania udev jako automountera we wcześniejszej odpowiedzi ; to (lub zasoby, do których prowadzi) może rzucić nieco światła na Ciebie.

Nie jest dla mnie jasne, jakie dokładnie jest twoje pytanie

• Odnośnie oddzielnych reguł dodawania i usuwania: możesz je skonsolidować, jeśli upuścisz dopasowanie ACTION , ale może to prowadzić do zbyt częstego uruchamiania reguły. Myślę, że lepiej jest wyraźnie dopasować każdą regułę. Lub jeszcze lepiej (z powodów omówionych w sekcji odmontowania poniżej), całkowicie zrezygnuj z reguły „usuń” .

• Odnośnie RUN działań w zasadach udev: RUN działania w regule udev musi zakończyć szybko . Spójrz na przykład, do którego linkowałem; zobaczysz, że istnieją dwa skrypty - uDev wywołuje jeden, który odwraca drugi, aby wykonać rzeczywiste podłączenie, umożliwiając pierwszemu zwrócenie kontroli przetwarzania z powrotem do uDev w odpowiednim czasie. Jeśli już to robisz, świetnie; jeśli nie, rozważ dostosowanie skryptów w podobny sposób.

• Jeśli chodzi o odmontowywanie: Miałem wiele problemów z automatycznym odmontowaniem po usunięciu urządzenia i ostatecznie zdecydowałem, że w ogóle nie będę używać reguły „usuń” . Zamiast tego napisałem osobny skrypt odmontowujący, który zastąpił zasadę „usuń” .
  
  Wynika to z faktu, że powinieneś dać systemowi tyle czasu, ile potrzeba, aby zamknąć urządzenie przed fizycznym usunięciem. Jedną rzeczą jest szarpanie dysku, jeśli system plików został zamontowany w trybie tylko do odczytu, ale pełny system plików do odczytu i zapisu powinien być w miarę możliwości demontowany. (Tak właśnie działa opcja „Bezpiecznie usuń dysk” w systemie Windows - jest to mechanizm odmontowywania dysku, zanim urządzenie zostanie fizycznie usunięte z systemu.)
  
  Dzięki zwykłemu systemowi plików udało mi się sprawić, że niektóre odmontowania będą działały „prawidłowo”, używając syncopcji w czasie montowania i umount -l(leniwe odmontowywanie) podczas odmontowywania. Leniwi odmontowują polecenie jądra, aby natychmiast odłączył system plików, ale odwołania do systemu plików później, gdy nie będą już zajęte. Ten rodzaj działa, ale nie jest tak bezpieczny dla danych, jak całkowite odmontowanie przed usunięciem urządzenia.
  
  Z tych samych powodów możesz mieć problemy z działaniem leniwego odmontowania w zaszyfrowanym systemie plików. Maper urządzeń dodaje kolejną warstwę złożoności oprócz standardowych problemów z systemem plików. Wydaje mi się, że dzięki temu zaszyfrowany system plików byłby jeszcze bardziej wrażliwy na nieczyste odinstalowania. (Nie mam jednak zbyt dużego doświadczenia z szyfrowaniem FS, więc mogą być w stanie to tolerować).

Mam nadzieję, że to daje pewne wskazówki. Szczerze mówiąc, do celów automatycznego montażu uDev jest wykonalny, ale nie idealny. Demon HalEvt lub nowszy devicekit prawdopodobnie byłby bardziej odpowiedni.