[pkg-cryptsetup-devel] Bug#1008503: cryptsetup-initramfs: Handle absolute keyfile path for derived key in cryptroot hook

[corubba]

Package: cryptsetup-initramfs
Version: 2:2.3.7-1+deb11u1
Severity: minor
Tags: patch

Dear Maintainer,

when using the `decrypt_derived` keyscript, the `cryptroot` initramfs hook expects the `key file` in `/etc/crypttab` to be the `target name` of another crypttab entry. Beside the runtime-use as argument to the keyscript, the `key file` is in this case also used during initramfs creation to make sure the "parent" is unlocked beforehand. And this all works fine. One thing I noticed thought is that systemd throws a few messages with such a setup. These appear after the initrd, so with the real root already mounted. (I slightly reordered the messages to increase readability)

```
ERROR systemd[1]: /run/systemd/generator/systemd-cryptsetup at luks\x2dtwo.service:14: RequiresMountsFor= path is not absolute, ignoring: luks-one
[...]
INFO systemd[1]: Starting Cryptography Setup for luks-one...
WARN systemd-cryptsetup[944]: Encountered unknown /etc/crypttab option 'initramfs', ignoring.
INFO systemd-cryptsetup[944]: Volume luks-one already active.
INFO systemd[1]: Finished Cryptography Setup for luks-one.
INFO systemd[1]: Starting Cryptography Setup for luks-two...
WARN systemd-cryptsetup[910]: Password file path 'luks-one' is not absolute. Ignoring.
WARN systemd-cryptsetup[910]: Encountered unknown /etc/crypttab option 'initramfs', ignoring.
WARN systemd-cryptsetup[910]: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
INFO systemd-cryptsetup[910]: Volume luks-two already active.
INFO systemd[1]: Finished Cryptography Setup for luks-two.
```

I am not worried about the three `Encountered unknown /etc/crypttab option` warnings, because they are valid; these options are specific to Debian's cryptroot hook. But the other two regarding the non-absolute key file bothered me a bit, especially because one is an error. Out of pure curiosity, I changed the key file in my crypttab from the target name `luks-one` to the absolute block device path `/dev/mapper/luks-one` to see what happens. To my surprise does the keyscript not *require* a target name as argument, it also works fine with a absolute device path. You get the same result when calling `./decrypt_derived luks-one` and `./decrypt_derived /dev/mapper/luks-one` (also works with `dev/disk/by-id/...` and others). And the error/warning from systemd are gone, plus it now actually adds `dev-mapper-luks\x2done.device` as a proper dependency to `systemd-cryptsetup at luks\x2dtwo.service`. The only thing that breaks when using a absolute device path is the recursive unlocking, which the hook will warn about during initramfs creation:

```
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
cryptsetup: WARNING: target '/dev/mapper/luks-one' not found in /etc/crypttab
```

This can be functionally worked around by not relying on the recursion and explicitly setting the initramfs option for all needed entries. But being annoyed by that warning, I took a dive into the cryptroot hook sourcecode and created the attached patch, which detects a absolute key file and runs it through `dmsetup` to resolve it to a target name. With that, both the `cryptroot` hook and `systemd-cryptsetup` work.

I saw a few comments in the scripts to not trust `/dev/mapper/` so I am not sure if this breaks anything with regards to name-mangling, but I am sure you subject experts will be able to easily assess that.


I also acknowledge that one could partially or completely disable the systemd-cryptsetup-generator using kernel command line parameters, but that would prevent using the generated device/service units directly or as dependencies for other units. Unfortunately there is no systemd-cryptsetup-generator specific crypttab option to only disable unit generation for specific entries. I haven't tried to mask the generated services for the hook-handled devices, that would probably also work; the services are effectively no-ops in that case anyway.


-- Package-specific info:
-- /proc/cmdline
root=/dev/vgmain/lvroot ro noresume quiet

-- /etc/crypttab
# <target name>   <source device>    <key file>              <options>
#these two are the pvs of vgmain
luks-one          UUID=xxxxxx        none                    luks,initramfs
luks-two          UUID=yyyyyy        /dev/mapper/luks-one    luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived

-- /etc/fstab
# <file system>               <mount point>     <type>    <options>       <dump>  <pass>
/dev/vgmain/lvroot            /                 xfs       defaults        0       1
/dev/disk/by-partlabel/esp    /boot/efi         vfat      umask=0077      0       2


-- System Information:
Debian Release: 11.3
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii  busybox-static [busybox]                1:1.30.1-6+b3
ii  cryptsetup                              2:2.3.7-1+deb11u1
ii  debconf [debconf-2.0]                   1.5.77
ii  initramfs-tools [linux-initramfs-tool]  0.140

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.205
ii  kbd            2.3.0-3

cryptsetup-initramfs suggests no packages.

-- debconf information:
   cryptsetup-initramfs/prerm_active_mappings: true
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cryptroot-hook-handle-absolute-keyfile-path-for-decr.patch
Type: text/x-patch
Size: 1003 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20220328/79ed5039/attachment.bin>