[pkg-cryptsetup-devel] Bug#917067: Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Guilhem Moulin]

On Sun, 23 Dec 2018 at 01:30:15 +0100, Mikhail Morfikov wrote:
> On 22/12/2018 16:48, Guilhem Moulin wrote:
>> Disk images, key files, and detached headers can reside on arbitrarily
>> complicated file systems and block device stack, and setting up these
>> stacks to make the files available prior to unlocking is really not the
>> job of our initramfs boot scripts.  I'm thus closing this bug as
>> ‘wontfix’, sorry.
>> 
> I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup
> one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If not, I
> can ask about this problem upstream, but I thought it is debian specific, so
> that's why I opened the issue here.

Indeed, you originally opened the bug against ‘cryptsetup-bin’ but there
is no crypttab(5)-handling logic in that package.  crypttab(5) doesn't
come from cryptsetup upstream but isn't Debian-specific either; systemd
normally (unless systemd-cryptsetup-generator(8) is disabled) reads
/etc/crypttab too, just like our own cryptdisks_start(8), initramfs
hooks and SysV init files.

Mapping dm-crypt devices can happen 1. at initramfs stage, 2. later
during the boot process by init(1), or 3. manually once the the system
has finished booting.  Since you disabled systemd-cryptsetup-generator(8)
it's only 1. and 3. left (anyway 2. is done by src:systemd not
src:cryptsetup when init(1) is systemd).  And if you want automatic
unlocking, only 1. left.
 
> That's why I asked if there's a way to use only the /etc/crypttab file
> to make it work.

If by “use only the /etc/crypttab” you mean use a crypttab(5)-handling
logic that is neither systemd-cryptsetup-generator(8) nor cryptdisks_start(8)
(either with .service files or with manual calls), then the device has
to be mapped at initramfs stage, and setup arbitrarily complex file
systems and/or device stacks isn't something our boot scripts are meant
to do.  For such use-case one needs to ensure prerequisites are present
in custom local-top or local-block scripts.  That's why I tagged this
bug as ‘wontfix’.
 
> If this can't/won't be done, I stick with the systemd service I have already,
> because it works just fine, though if I moved from systemd to other init, it
> would stop.

IMHO the right way support to your use-case would be to add support for
keyscripts in systemd (#618862).  Meanwhile, an alternative to your
custom .service file is to unmask cryptdisks.service and add a unit
override to ensure the required file systems are mounted before hand.
(It should work in your case since AFAIU all other crypttab(5) entries
are mapped at initramfs stage, but I wouldn't recommend it as a general
workaround for the lack of keyscript support in systemd, because
keyscripts might introduce races or require a TTY, and the prerequisites
need to be written down by hand.)

If your encrypted disk image is in LUKS2 format (otherwise upgrade from
LUKS1 possible) you can also get away without workaround if you don't
mind re-enabling systemd-cryptsetup-generator(8).  First you need to add
a keyring token for that device:

    cryptsetup token add --key-slot 0 --key-description cryptkey-c1 /home/me/luks/some.img

(The “cryptkey-” prefix in the key description comes from
decrypt_keyctl, but is currently undocumented.  If it ever changes you'd
be prompted for the passphrase — something which anyway will happen if
the key expires before all devices have been opened — but I guess we
could just document the prefix.)

Then with a “simple” crypttab(5) entry (without keyscript)

    some_img    /home/me/luks/some.img  none  luks

systemd should be able to open the device in an unattended fashion, if
one of the devices unlocked earlier (at initramfs stage) have ‘c1’ as
third column ‘keyscript=decrypt_keyctl’ in the crypttab(5) option column.
Cf. https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/Keyring.txt
for details.

-- 
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/20181223/c12c8f7e/attachment.sig>