Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1053103

Bug#983708: passdev and systemd use conflicting syntax for keyfile

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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

Hi,

On Sun, 28 Feb 2021 at 19:11:56 +0100, schaarsc@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.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#983708: passdev and systemd use conflicting syntax for keyfile schaarsc@gmx.de - 2021-02-28 19:20 +0100
  Bug#983708: passdev and systemd use conflicting syntax for keyfile Guilhem Moulin <guilhem@debian.org> - 2021-03-20 20:40 +0100

csiph-web