Encrypted root using key-file should not require custom key-script

Bug #552658 reported by TJ
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

Binary package hint: cryptsetup

From Hardy through to Karmic it was necessary to use a custom keyscript option to unlock encrypted volumes where the unlock key resides on an external device, typically a USB key:

--- /etc/crypttab ---
root /dev/mapper/Ubuntu-Karmic_encrypted /home/tj/keyfile luks,keyscript=/usr/local/sbin/crypto-usb-key.sh
var /dev/mapper/Ubuntu-Lucid_var_encrypted /home/tj/keyfile luks,keyscript=/usr/local/sbin/crypto-usb-key.sh
home /dev/mapper/Ubuntu-home /home/tj/keyfile luks,keyscript=/usr/local/sbin/crypto-usb-key.sh
------

The external keyscript is responsible for ensuring the device's driver is loaded, that the device has 'settled', that the appropriate file-system driver is loaded, and then mounts the file-system and copies the key-file contents to STDOUT. My particular keyscript adds the key-file path found in "/etc/crypttab" to the mount-point (e.g. /tmp/key/) in order that the path in 'crypttab' is valid when the system is in normal operation. This simply makes locating the key-file consistent whether during initramfs or later.

In Luicd it is possible to do away with the custom keyscript for volumes other than the root file-system by using the "/etc/default/cryptdisks" option:

CRYPTDISKS_MOUNT="/media/USB"

where there also exists in "/etc/fstab" a mount entry for the device:

# USB key
LABEL=USB /media/USB auto defaults 0 2

And "/etc/crypttab" looks something like this:

root /dev/mapper/Ubuntu-Lucid_encrypted /home/tj/keyfile luks,keyscript=/usr/local/sbin/crypto-usb-key.sh
var /dev/mapper/Ubuntu-Lucid_var_encrypted /media/USB/home/tj/keyfile luks
home /dev/mapper/Ubuntu-home /media/USB/home/tj/keyfile luks

However, I've not been able to discover a way to use cryptsetup's non-custom scripts and configuration to have it unlock the encrypted root file-system. In particular, I found that removing the "keyscript=" option results in *no* "/conf/conf.d/cryptroot" file in the initramfs image and therefore the system fails to start and is not manually recoverable from the busybox shell.

My feeling is that cryptsetup should still create "/conf/conf.d/cryproot". Additionally, cryptsetup should have the 'knowledge' to mount an external device containing the key-file by analysing 'fstab' and 'crypttab' during the initramfs phase in the same way it does for the later encrypted volumes.

The benefit of this facility would be to do away with the need to test (every 6 months for each new release) the custom keyscript and figure out changes to fix bugs (e.g. Lucid doing away with usplash in favour of plymouth means the keyscript code to write messages to console or usplash have to be rewritten to work with plymouth, which means learning how plymouth works).

It would also introduce an "It Just Works" solution to what is still a quite complicated scenario.

TJ (tj)
Changed in cryptsetup (Ubuntu):
importance: Undecided → Wishlist
summary: - Encrypted root using key-file requires custom key-script
+ Encrypted root using key-file should not require custom key-script
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.