[systemd-devel] Mounting luks devices: passphrase, keyctl, etc.

[Carles Pina i Estany]

Hi!

TL;DR: systemd can mount a cyphered partition without entering the
passphrase (passphrase is the same to the other partitions mounted by
initrd). How does systemd mount it?

I'm trying to understand something regarding the boot process. It works
but I can't understand why or how it works! (and I like to understand
how the computer boots). Sorry for the long email, I can provide more
information if needed!

I'm using Debian Stretch 9.5 with three cyphered partitions. During a
normal booting process I'm asked by initrd /lib/cryptsetup/askpass for
the password of two of them (root + swap, as per initrd). Then systemd
mounts the third one without asking the password (it's in /etc/crypttab, a copy-paste of the crypttab -there is no script related to keyctl...):

m2_root_crypt UUID=4e655198-a111-... none luks,discard
m2_swap_crypt UUID=56485640-8a04-... none luks,discard
ssd_dades_crypt UUID=8d1d855d-17a7-... none luks,discard

After a boot I see using keyctl show:
root at pinux:~# keyctl show
Session Keyring
 479651357 --alswrv      0 65534  keyring: _uid_ses.0
 712333474 --alswrv      0 65534   \_ keyring: _uid.0
 711077095 --alswrv      0     0       \_ user: cryptsetup

I'm reading Debian initrd scripts and I can't see any place that would make the
key to be added in the kernel keyring.

Actually if I boot with break=init or init=/bin/bash the two initial partitions
are mounted (since both are in the initrd scripts) but /proc/keys doesn't have
the cryptsetup line. So it seems that it's not being saved there by Debian
initrd scripts.

I see the code (systemd-232, in src/shared/ask-password-api.c) where the
password would be saved there if the user entered it using systemd.

The password agent used by initrd is plymouth but I can't see any plymouth
capability for storing password (from the initrd to the final system, or any
trace of this).

Any clues how systemd is mounting it without me entering the password to a
systemd process (as far as I can tell?). I can provide logs or more information
if needed but maybe is something obvious.

BTW, the fact that the key is stored/used there is easy to test with:
systemctl stop systemd-cryptsetup at ssd_dades_crypt.service
systemctl start systemd-cryptsetup at ssd_dades_crypt.service # will not be asked if the key was stored... during the mystery boot process or because of a recent systemctl start...

Thank you,

-- 
Carles Pina i Estany
	Web: http://pinux.info || Blog: http://pintant.cat
	GPG Key 0x8CD5C157