[pkg-cryptsetup-devel] Bug#930696: Bug#930696: Keyfiles specified by KEYFILE_PATTERN are not added to the initramfs
guilhem at debian.org
Wed Jun 19 00:36:22 BST 2019
Control: severity -1 minor
On Tue, 18 Jun 2019 at 20:35:47 +0200, Jernej Jakob wrote:
> Any keyfiles configured in /etc/cryptsetup-initramfs/conf-hook
> KEYFILE_PATTERN are not added to the initramfs if the target in
> /etc/crypttab also has keyscript set.
As crypttab(5) reads,
“In case of a keyscript, the value of [the third] field is given as
argument to the keyscript.”
This could probably be made clearer, but the behavior is intentional: it is
*not* treated as a key file, hence not compared against the KEYFILE_PATTERN
> This may prevent the system from booting if the target has a
> keyscript=/bin/cat set (as is in PureOS which is based on buster).
Setting ‘keyscript=/bin/cat’ is useless for unlocking by key file, and
is discouraged as it's incompatible with setups not supporting
keyscripts, like systemd's systemd-cryptsetup at .service. The same entry
without the key script should work just fine.
> Perhaps cryptroot should print out a warning that the keyfile set in
> crypttab wasn't added due to a set keyscript. That way the users would
> know something may be misconfigured.
I'm reluctant to do that due to false positives. Consider a setup with
two devices unlocked at initramfs stage, one opened by key file (copied
to the initramfs image), one by key script, and KEYFILE_PATTERN set to
"*". Nothing wrong with that setup, KEYFILE_PATTERN="*" indicates that
all key files should be copied to the initramfs image; crypttab(5)
entries with a ‘keyscript=’ option are intentionally excluded from
glob(7)'ing printing any warning would be a false positive.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the pkg-cryptsetup-devel