udev: Montar o volume criptografado após a inserção do pen drive

Question

Eu tenho uma partição criptografada que gostaria de montar automaticamente quando insiro um pendrive contendo a chave e gostaria de desmontá-la (e fechar o mapeador) quando o bastão for removido. Eu estou usando o Ubuntu Karmic.

Parece haver alguns projetos que tentam isso para TrueCrypt (por exemplo, link ), mas nada baseado em dmcrypt / LUKS. Então eu pensei em tentar a minha sorte escrevendo uma regra do udev. Depois de muitas horas frustrantes, descobri isso:

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"

Funciona, mas não é legal. O problema aqui é que a primeira regra não coincide com a remoção, a segunda não combina com a adição.

udevadm monitor --property mostra isso (e praticamente a mesma coisa em "adicionar").

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

Isso parece conter todos os dados que seriam necessários para corresponder às duas regras nos dois casos (adicionar, remover).

Por razões de integridade, aqui está a saída de 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"

 ....

Alguém pode lançar alguma luz sobre isso?

    

Answer 1

Eu escrevi algumas informações sobre como usar o udev como montador automático em um resposta anterior ; ele (ou os recursos aos quais ele se vincula) pode lançar alguma luz para você.

Não está claro para mim qual é exatamente a sua pergunta

• Em relação a adicionar & remover regras: você pode consolidá-las se eliminar a correspondência ACTION , mas isso pode fazer com que a regra seja acionada com muita frequência. Acho melhor combinar explicitamente cada regra. Ou melhor ainda (por razões discutidas na seção desmontar abaixo), elimine completamente a regra "remover" .

• Com relação às ações RUN nas regras do uDev: a ação RUN na sua regra do uDev precisa ser concluída . Dê uma olhada no exemplo ao qual me vinculei; você verá que existem dois scripts - o uDev chama um, o que faz o outro rodar para fazer a montagem real, permitindo que o primeiro retorne o controle de processamento de volta ao uDev em tempo hábil. Se você já está fazendo isso, ótimo; caso contrário, considere ajustar seus scripts de maneira semelhante.

• Em relação a desmontagens: eu tive muitos problemas ao desmontar automaticamente a remoção de dispositivos, e finalmente decidi não usar "remover" regra em tudo. Em vez disso, escrevi um script unmounter separado que substituiu a regra "remover" .
  
  Isso é porque você deve realmente dar ao sistema o tempo necessário para fechar o dispositivo antes de removê-lo fisicamente. Uma coisa é arrancar uma unidade se você montou o sistema de arquivos somente leitura, mas um sistema de arquivos de leitura e gravação completo deve ser desmontado sempre que possível. (Isso é o que a opção "Remover a unidade com segurança" no Windows faz - é um mecanismo para desmontar a unidade antes que o dispositivo seja fisicamente removido do sistema).
  
  Com um sistema de arquivos regular, eu consegui algumas desmontagens funcionando "apropriadamente" usando a opção sync no tempo de montagem e umount -l (desmontagens lentas) ao desmontar. As desordens preguiçosas dizem ao kernel para desanexar o sistema de arquivos imediatamente, mas limpando as referências ao sistema de arquivos mais tarde, quando elas não estiverem mais ocupadas. Esse tipo de trabalho funciona, mas não é tão seguro para os dados fazer uma desmontagem completa antes de remover o dispositivo.
  
  Você pode ter dificuldade em fazer com que as desmontagens ociosas funcionem com um sistema de arquivos criptografado, pelas mesmas razões. O mapeador de dispositivos adiciona mais uma camada de complexidade sobre os problemas padrão do sistema de arquivos. Parece-me que isso tornaria um sistema de arquivos criptografado ainda mais sensível a desmontagens impuras. (Eu não sou muito experiente com FSs criptografados, então eles podem ser capazes de tolerar isso.)

Espero que isso lhe dê algumas dicas. Francamente, para fins de montagem automática, o uDev é viável, mas não ideal. O HalEvt daemon ou o mais novo DeviceKit provavelmente seria mais apropriado.