[pkg-cryptsetup-devel] Bug#983708: passdev and systemd use conflicting syntax for keyfile

[Guilhem Moulin]

Control: reassign -1 systemd 247.3-1
Control: retitle -1 systemd-cryptsetup at .service should ignore targets that are already mapped

Hi,

On Sun, 28 Feb 2021 at 19:11:56 +0100, schaarsc at gmx.de wrote:
> Package: cryptsetup-initramfs
> Version: 2:2.3.4-2~bpo10+2
> 
> systemd  247.2-5~bpo10+1
> 
> I recently switched to buster-backports and noticed an issue that (I think) could potentially break
> systems migrating to bullseye.
> On a system having encrypted root, keyfile on usb-stick and multiple btrfs subvolumes, the system
> fails to mount all subvolumes.
> 
> If there is no solution, then maybe a hint in the README could be added.

We (src:crypttab) have precise semantics crypttab(5)'s 3rd column (after
unescaping octal-sequences):

 - if a key script is used, the value of the 3rd column is used as 1st
   positional argument;
 - if the value is "none", the passphrase is read interactively from the
   console;
 - otherwise the assume is assumed to be an existing file or
   block/character device and the passphrase is read from it.

In particular, one might very well use a key file named ‘/etc/my.key:LABEL=keydev’
in the 3rd column, or use ‘foo:bar:baz’ and have a custom keyscript
split the string and interpret it as 3 arguments.  (Our passkev key
script does that with ‘blockdev:keyfile’ for instance.)

I'm thus reassign this to systemd.  With systemd 241-7~deb10u6
‘/etc/my.key:LABEL=keydev’ is interpreted as the path to a key file,
while after upgrading to Bullseye it ignores that file and waits for a
block device with label ‘keydev’ to show up.  This is arguably not a
severe regression though. :-)

However the device might have been mapped at an earlier stage (for
instance at initramfs stage), and systemd-cryptsetup-generator should
not generate units in that case; unlocking might have been done using a
crypttab(5) entry systemd doesn't understand, cf. for instance -1 or
#618862.  At the very least it shouldn't delay the boot or end up in a
failed state.

AFAICT while systemd delays the boot until the device lookup timeouts
(and ends up in a failed state), if the mapped target contains a file
system with a matching fstab(5) entry then systemd does mount it.  But
unlike the OP I've only tried with ext4 not multi-volume btrfs.

Cheers
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20210320/ee24bb0f/attachment.sig>