[pkg-cryptsetup-devel] Bug#758788: Bug#758788: cryptsetup: Passphrase caching broken in decrypt_keyctl

[Jonas Meurer]

Hey Luc,

Am 12.10.2014 um 12:57 schrieb Luc Maisonobe:
> Here are some news about the analysis of this boot problem.

First, great that you finally managed to use the debugging version that
I sent earlier.

> First, starting and stopping test partitions with cryptdisks_start and
> cryptdisks_stop does work properly after the computer has boot, but does
> not work at boot time. Here is the example of the command (with
> decrypt_keyctl modified to display the keys at the end, as suggested in
> an earlier post).
> 
> root at marislae:/lib/systemd/system# cryptdisks_start sda3_crypt
> [....] Starting crypto disk...[info] sda3_crypt (starting)...
> Caching passphrase for
> /dev/disk/by-uuid/4f04656d-00fc-4fea-8c8a-44a7bdc7b6e5:  ******
> BEGIN DECRYPT_KEYCTL DEBUG OUTPUT
> id: cryptkey-pw1 | key id: 657815207
> key content: testpw
> key list:
> 1 key in keyring:
> 657815207: --alswrv     0     0 user: cryptkey-pw1
> END DECRYPT_KEYCTL DEBUG OUTPUT
> 
> [ ok crypt (started)...done.
> root at marislae:/lib/systemd/system# cryptdisks_start sda5_crypt
> [ ok ] Starting crypto disk...sda5_crypt (running)...done.
> root at marislae:/lib/systemd/system#
> 
> As you can see, running it on an already started system is fine.

Looks good so far.

> On the other hand, the same setting does not work at boot time.
> 
> Back to the original problem, without the test partitions and using only
> my regular two work partitions sda5 and sdb1 holding LVM volumes. The
> modification of the decrypt_keyctl to display the key on boot showed
> that after the key for the first partition was entered, it was stored in
> the user keyring. I got something like:
> 
> id: cryptkey-sda5b1 | key id: 1007139041
> key list:
> 1 key in keyring:
> 1007139041: --alswrv      0     0 user: cryptkey-sda5b1
> 
> Then the system asked for the second key, ignoring the one it already
> known, and the following is displayed:
> 
> id: cryptkey-sda5b1 | key id: 422064942
> key list:
> 1 key in keyring:
> 422064942: --alswrv      0     0 user: cryptkey-sda5b1
> 
> So the id was exactly the same, but the key id was a new one. It seems
> the keyring is cleared sometime between the two runs of the script and
> in each case only one key was stored in the keyring. I think the culprit
> is there: why did key 1007139041 disappear from keyring between the two
> commands?

Is this output from the boot process or did you try to unlock the
encrypted LVM volumes after boot process finished?

> Another important information is that this system uses systemd, and it
> seems decrypting is handled differently with systemd. If I run
> journalctl to get information, I see this message:

This information changes everything! I never tried systemd myself so far
and I don't know nothing about how the systemd boot process handles
dm-crypt devices/cryptdisks/crypttab at all.

> oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Password file path
> 'sda5b1' is not absolute. Ignoring.
> oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Encountered unknown
> /etc/crypttab option 'keyscript=decrypt_keyctl', ignoring.

This looks suspicious to me. Maybe systemd has its own crypttab
implementation which doesn't support all the crypttab options/functions
from Debian sysvinit init and initramfs scripts? At least some
'systemd-cryptsetup' process seems to process crypttab entries and
detects an unsupported option 'keyscript'.

> oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Volume sda5_crypt
> already active.

At the same time, the encrypted device is detected as 'already active'.
Doesn't make sense to me.

But nevertheless, I can imagine that systemd-cryptsetup detects unknown
crypttab options and falls back to the default password prompt
afterwards. That would explain why you're asked for the password of
every encrypted device.


> oct. 12 12:08:05 marislae systemd-cryptsetup[575]: Password file path
> 'sda5b1' is not absolute. Ignoring.
> oct. 12 12:08:05 marislae systemd-cryptsetup[575]: Encountered unknown
> /etc/crypttab option 'keyscript=decrypt_keyctl', ignoring.
> oct. 12 12:08:05 marislae systemd-cryptsetup[575]: Volume sdb1_crypt
> already active.
> 
> However, this message seems to be generated after the partitions have
> already been activated, and from the message displayed on the console, I
> know decrypt_keyctl did run, despite these messages.

Ok, another option would be that the initscript is executed first, and
afterwards the systemd-cryptsetup helper binary iterates over crypttab
entries again and detects that the devices are already unlocked.

> Yet another information is I noticed earlier in journalctl the message
> oct. 12 12:08:05 marislae systemd[1]: /usr appears to be on its own
> filesytem and is not already mounted. This is not a supported setup.
> This problem is explained here:
> <http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/>.
> I don't know if it is related to my problem, I will try to fix this by
> moving /usr content into the / partition and see if it helps.

Yeah, I remember I've read somewhere that systemd doesn't support
separate /usr partitions. But again, I don't know nothing about systemd
yet. Never tried it so far.

So I don't even know at which state systemd executes the cryptdisks
initscript, and how it interacts with the kernel keyrings.

I'm eager to say that your problems are related to systemd init system.
Honestly, I don't know when I will find time to give systemd a try and
further debug this issue :-/

Cheers,
 jonas