Luca Boccassi <bl...@debian.org> writes: > On Mon, 17 Feb 2025 22:27:15 +0100 =?utf-8?Q?=C5=81ukasz_Stelmach?= > <steel...@post.pl> wrote: >> >> Dear Maintainer, >> >> Since there is some discrepancy between crypttab options (4th column) >> supported by systemd-cryptsetup-generator and Debian's script running >> in the initrd to set up encrypted volumes. The attached patch makes >> the generator skip any entry from crypttab if its 4th column contains >> Debian specific options. This probably won't fix all the possible >> problems occurring in Debian due to using two different tools but it >> will help eliminating some. > > Sorry, out-of-tree patches are not allowed,
I share your passion for keeping such patchase as far away from
a downstream repo as possible. Please allow me to draw the bigger
picture, which I faild to do in the previous message. I expect you won't
change your mind but maybe you can point me in the right direction to
solve the problem which I belive is real.
> and it is very unlikely something like this can be upstreamed.
As I explain below this was never meant for upstream.
> Instead, please send a PR upstream to make the generator skip
> parameters starting with 'x-' as it is customary in other configuration
> settings, and then change the Debian-specific scripts to use that
> prefix for Debian-specific options. This is something that is very
> likely to be accepted upstream.
I am afraid this isn't viable solution as the options in question have
long been documented in Debian's crypttab(5) from the cryptsetup
package and renaming them would break running configurations.
The Bigger Picture
Currently there are two packages in Debian that parse /etc/crypttab and
attach encrypted volumes: systemd and cryptsetup (precisely Debian
scripts provided in this package). They both document options they
support in their versions of crypttab(5) (see the table below). They
(obviously) aren't marked as conflicting. The latter package, however,
is used by initramfs-tools which is the default to build initramfs
images in Debian.
This, I guess, makes systemd-cryptsetup-generator provided in a Debian
package slightly more responsible for not producing bogus output.
Let me describe my particular case that triggered me to creat this
patch. I've got laptop with an encrypted LVM PV that holds rootfs. To
unlock it I have used a keyfile stored on a usb stick. (Yes, this isn't as
secure as FIDO2 device but with proper handling and in my threat model
it is perfectly acceptable, and debian has supported it for years.) The
crypttab line to attach the PV looks like this:
sda2_crypt UUID=foo-bar-baz UUID=baz-bar-foo:/key_lvm
luks,keyscript=passdev
foo-bar-baz - the uuid of the luks volume
baz-bar-foo - the uuid of file system on the USB stick that holds key
file
/key_lvm - the keyfile
keyscript - the program to run to derive a key from the key column of
crypttab
systemd-crypttab-generator also supports reading a key file from a
filesystems BUT it requires the filename to be before the colon and the
filesystem behind it (/key_lvm:UUID=baz-bar-foo). Hence, it produces
nonsense keydev-*.mount units (see the What)
--8<---------------cut here---------------start------------->8---
[Unit]
DefaultDependencies=no
[Mount]
What=/key_lvm
Where=/run/systemd/cryptsetup/keydev-sda2_crypt
Options=ro
--8<---------------cut here---------------end--------------->8---
as well as the ExecStart in systemd-cryptsetup@*.service units (see 4th
argument)
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'sda2_crypt'
'/dev/disk/by-uuid/foo-bar-baz
'/run/systemd/cryptsetup/keydev-sda2_crypt/UUID=baz-bar-foo
'luks,keyscript=passdev'
(The key file name and the id of the filesystem it is supposed to be on
are switched in those two units.)
These bogus units produce errors during (luckily sucessful otherwise)
boot. I haven't tested other configurations valid for Debian script but
unsupported by systemd, but I expect there might be more issues like
this.
The Conclusion
There are ways to work around these problems, I know, but they are just
that (documenting them may be a solution). IMHO
systemd-cryptsetup-generator provided in a Debian package should not
produce bogus output from a configuration file that is valid for the
other package that doesn't conflict with systemd. That is why I believe
my patch should be added to those ./debian/patches/debian directory of
the systemd package. If you think the patch isn't the right solution (I
don't insist), can you suggest a different one I could implement.
The Table Below
Options supported by different Debian packages.
| Option | systemd | cryptsetup |
|--------------------------+---------+------------|
| check | | + |
| checkargs | | + |
| fvault | | + |
| initramfs | | + |
| keyscript | | + |
| keyslot | | + |
| loud | | + |
| noearly | | + |
| quiet | | + |
| same-cpu-crypt | | + |
| veracrypt | | + |
| verify | | + |
| discard | + | |
| fido2-* | + | |
| headless | + | |
| keyfile-erase | + | |
| keyfile-timeout | + | |
| link-volume-key | + | |
| _netdev | + | |
| nofail | + | |
| password-cache | + | |
| password-echo | + | |
| pkcs11-uri | + | |
| tcrypt-hidden | + | |
| tcrypt-keyfile | + | |
| tcrypt-system | + | |
| timeout | + | |
| token-timeout | + | |
| tpm2-* | + | |
| try-empty-password | + | |
| veracrypt-pim | + | |
| x-initrd.attach | + | |
| x-systemd.device-timeout | + | |
| bitlk | + | + |
| cipher | + | + |
| hash | + | + |
| header | + | + |
| keyfile-offset | + | + |
| keyfile-size | + | + |
| key-slot | + | + |
| luks | + | + |
| noauto | + | + |
| no-read-workqueue | + | + |
| no-write-workqueue | + | + |
| offset | + | + |
| plain | + | + |
| read-only | + | + |
| readonly | + | + |
| sector-size | + | + |
| size | + | + |
| skip | + | + |
| submit-from-crypt-cpus | + | + |
| swap | + | + |
| tcrypt | + | + |
| tcrypt-veracrypt | + | + |
| tmp | + | + |
| tries | + | + |
--
Kind regards,
Łukasz Stelmach
signature.asc
Description: PGP signature
