On Sun, 23 Dec 2018 at 01:30:15 +0100, Mikhail Morfikov wrote: > On 22/12/2018 16:48, Guilhem Moulin wrote: >> Disk images, key files, and detached headers can reside on arbitrarily >> complicated file systems and block device stack, and setting up these >> stacks to make the files available prior to unlocking is really not the >> job of our initramfs boot scripts. I'm thus closing this bug as >> ‘wontfix’, sorry. >> > I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup > one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If > not, I > can ask about this problem upstream, but I thought it is debian specific, so > that's why I opened the issue here.
Indeed, you originally opened the bug against ‘cryptsetup-bin’ but there is no crypttab(5)-handling logic in that package. crypttab(5) doesn't come from cryptsetup upstream but isn't Debian-specific either; systemd normally (unless systemd-cryptsetup-generator(8) is disabled) reads /etc/crypttab too, just like our own cryptdisks_start(8), initramfs hooks and SysV init files. Mapping dm-crypt devices can happen 1. at initramfs stage, 2. later during the boot process by init(1), or 3. manually once the the system has finished booting. Since you disabled systemd-cryptsetup-generator(8) it's only 1. and 3. left (anyway 2. is done by src:systemd not src:cryptsetup when init(1) is systemd). And if you want automatic unlocking, only 1. left. > That's why I asked if there's a way to use only the /etc/crypttab file > to make it work. If by “use only the /etc/crypttab” you mean use a crypttab(5)-handling logic that is neither systemd-cryptsetup-generator(8) nor cryptdisks_start(8) (either with .service files or with manual calls), then the device has to be mapped at initramfs stage, and setup arbitrarily complex file systems and/or device stacks isn't something our boot scripts are meant to do. For such use-case one needs to ensure prerequisites are present in custom local-top or local-block scripts. That's why I tagged this bug as ‘wontfix’. > If this can't/won't be done, I stick with the systemd service I have already, > because it works just fine, though if I moved from systemd to other init, it > would stop. IMHO the right way support to your use-case would be to add support for keyscripts in systemd (#618862). Meanwhile, an alternative to your custom .service file is to unmask cryptdisks.service and add a unit override to ensure the required file systems are mounted before hand. (It should work in your case since AFAIU all other crypttab(5) entries are mapped at initramfs stage, but I wouldn't recommend it as a general workaround for the lack of keyscript support in systemd, because keyscripts might introduce races or require a TTY, and the prerequisites need to be written down by hand.) If your encrypted disk image is in LUKS2 format (otherwise upgrade from LUKS1 possible) you can also get away without workaround if you don't mind re-enabling systemd-cryptsetup-generator(8). First you need to add a keyring token for that device: cryptsetup token add --key-slot 0 --key-description cryptkey-c1 /home/me/luks/some.img (The “cryptkey-” prefix in the key description comes from decrypt_keyctl, but is currently undocumented. If it ever changes you'd be prompted for the passphrase — something which anyway will happen if the key expires before all devices have been opened — but I guess we could just document the prefix.) Then with a “simple” crypttab(5) entry (without keyscript) some_img /home/me/luks/some.img none luks systemd should be able to open the device in an unattended fashion, if one of the devices unlocked earlier (at initramfs stage) have ‘c1’ as third column ‘keyscript=decrypt_keyctl’ in the crypttab(5) option column. Cf. https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/Keyring.txt for details. -- Guilhem.
signature.asc
Description: PGP signature