Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have an encrypted partition which I would like to mount automatically when I insert a usb stick containing the key, and I'd like to unmount it (and close the mapper) when the stick is removed. I am using Ubuntu Karmic.

There seem to be a couple projects which attempt this for TrueCrypt (for example, http://sourceforge.net/projects/tc-wrapper/), but nothing based on dmcrypt/LUKS. So I thought I'd try my luck with writing a udev rule. After many frustrating hours, I came up with this:

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"

It works, but isn't nice. The problem here is that the first rule won't match on removal, the second one won't match on addition.

udevadm monitor --property shows this (and pretty much the same thing on "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

This seems to contain all the data that would be necessary to match both rules in both cases (add, remove).

For completeness' sake, here is the output of 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"

 ....

Can anybody shed some light on this?

share|improve this question
    
so... is there a particular problem you're having, or is this just a general "udev+encrypted fs advice please" question? –  quack quixote Jan 27 '10 at 2:50
add comment

1 Answer 1

up vote 1 down vote accepted

I've written up some info on using udev as an automounter in an earlier answer; it (or the resources it links to) may shed some light for you.

It's not clear to me what exactly your question is

  • Regarding separate add & remove rules: You might be able to consolidate them if you drop the ACTION match, but that might lead to the rule firing too often. I think it's better to explicitly match each rule. Or better yet (for reasons discussed in the unmount section below), drop the "remove" rule altogether.

  • Regarding RUN actions in the uDev rules: The RUN action in your uDev rule needs to complete quickly. Take a look at the example I linked to; you'll see that there are two scripts -- uDev calls one, which spins off the other to do the actual mount, allowing the first to return processing control back to uDev in a timely manner. If you're already doing this, great; if not, consider tweaking your scripts in a similar fashion.

  • Regarding unmounts: I had a lot of trouble with automatically unmounting on device removal, and I eventually decided not to use a "remove" rule at all. Instead, I wrote a separate unmounter script that replaced the "remove" rule.

    This is because you should really give the OS as much time as it needs to close the device before you physically remove it. It's one thing to yank a drive if you've mounted the filesystem read-only, but a full read-write filesystem should be cleanly dismounted whenever possible. (This is what the "Safely Remove Drive" option in Windows does -- it's a mechanism for unmounting the drive before the device is physically removed from the system.)

    With a regular filesystem, I was able to get some unmounts working "properly" by using the sync option at mount time and umount -l (lazy unmounts) when unmounting. The lazy unmounts tell the kernel to detach the filesystem immediately, but cleanup references to the filesystem later, when they are no longer busy. This kind of works, but it's not as safe for the data as doing a full unmount before removing the device.

    You may have trouble making lazy unmounts work with an encrypted filesystem, for the same reasons. The device mapper adds yet another layer of complexity on top of the standard filesystem issues. It seems to me this would make an encrypted filesystem even more sensitive to unclean dismounts. (I'm not very experienced with encrypted FSs, though, so they may be able to tolerate it.)

Hopefully that gives you some pointers. Frankly, for automounting purposes, uDev is workable but not ideal. The HalEvt daemon or the newer DeviceKit would probably be more appropriate.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.