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

[Luc Maisonobe]

Here are some news about the analysis of this boot problem.

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.

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?

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:

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.
oct. 12 12:08:05 marislae systemd-cryptsetup[574]: Volume sda5_crypt
already active.
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.

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.

best regards,
Luc