I think it's probably common for people to have encrypted partitions on disc and have the keys stored on usb devices (which are also probably encrypted). With the current scripts, this is not possible for a few reasons: 1) if you need to mount a usb key before you start to decrypt another partition, it's not possible. Pre_mount/Post_mount don't work like this, they only run before mounts (which happen in the localfs addon, not the checkfs one) 2) if you wanted to unmount the usb key after certain partitions were decrypted, you could do it with post_mount, but it's really a post decryption thing. 3) USB devices seem to have problem when they are decrypted during checkfs. I thought this might be related to the usbfs mount in localmount, but it's something else. Anyway, I have found that if I decrypt a USB key in the regular cryptfs way, the resulting /dev/mapper/crypt-usb target is not mountable; if I luksClose it, and then luksOpen it again, it works fine. I tried moving some of the usb code from localmount into checkfs before the dm-crypt addon, but this didn't help Here's how we could address these problems: 1) add pre_crypt variables. I hacked it myself here for testing, added this to line 38 of /lib/rcscripts/addons/dm-crypt-start.sh: if [[ -n ${pre_crypt} ]] ; then ebegin " Running pre_crypt commands for ${target}" eval "${pre_crypt}" > /dev/null ewend $? || cryptfs_status=1 fi You also have to add pre_crypt=* somewhere, and you have to make it a local var like the others.. but that's easy. 2) add post_crypt actions. This shouldn't be any harder than the solution in #1, and it's necessary since people probably don't want to have the usb key mounted the whole time they're using the machine. 3) somehow make it so that USB devices can be decrypted in cryptfs... Again, I can't tell why they're not working, but it could be related to other filesystems not being mounted yet, stuff like that... (though adding proc/shm/usbfs stuff to checkfs didn't fix it) Here's why we should fix these problems: 1) two of them are pretty trivial to implement and pretty useful anyway. 2) I suppose this is/could be a common usage of the cryptfs script. For people who can't boot from USB sticks or make their own initrd's to have completely encrypted root FS's, this is a good way to get more stuff encrypted (while also having the security of a needed USB key, etc) 3) I have it implemented in a separate script that runs much later in the init process, and this has the following disadvantages: a) can't depent on dump/pass values in fstab to make sure my encrypted partitions get scanned (because checkfs is too early to know that they're encrypted, and it tries to check yet unmounted partitions. b) can't have encrypted /var, only less important stuff like home. This is because it's not so elegant to suddenly remount /var when it's already being used (loggers, pid files, etc). c) although it seems to work somewhat well, it seems risky to have partitions unmounted by scripts in the default runlevel, what if the filesystems don't unmount, then the volume will fail, and i'll lose data (and I won't know because fsck won't run unless i force it to, or script it in somehow) d) it would be much more elegant to have all of this working in cryptfs, it seems like aside from problem #3, it is almost at this level...
Please check cryptsetup-luks -r3 and you'll see a complete rewrite of the way things are done giving you all of the functionality (and more) that you list.
