[pkg-cryptsetup-devel] Bug#758788: solved!

[Luc Maisonobe]

I finally managed to understand and solve the issue (well, at least the
following fix works for me).

The decrypt_keyctl properly managed the key and stored it into the
root user keyring, where it is stored for 60 seconds.

After the first partition was decrypted, the script was called a second
time to get the key for the second partition, and it fact the key was
still in the keyring at that time. However, each time decrypt_keyctl was
called *during the boot process*, the environment variable
CRYPTTAB_TRIED was set to 3 and not 0 as expected for a first try.

The fact CRYPTTAB_TRIED was positive implied the decrypt_keyctl thought
that the key present in the keyring was wrong, and it is the script
itself that removed it using

  keyctl unlink $KID_ @u

So the decrypt_keyctl behaved correctly assuming the number of previous
tried was 3, which in fact was wrong. The problem was therefore: why is
CRYPTTAB_TRIED set to 3 even on the first call?

This variable is set at several places in
/lib/cryptsetup/cryptdisks.functions, but it is also set in
/usr/share/initramfs-tools/scripts/local-top/cryptroot. I'm not sure how
the various components are scheduled.

Looking at the setting in
/usr/share/initramfs-tools/scripts/local-top/cryptroot, there is a shell
loop that starts as follows:

        # Try to get a satisfactory password $crypttries times
        count=0
        while [ $crypttries -le 0 ] || [ $count -lt $crypttries ]; do
                export CRYPTTAB_TRIED="$crypttries"
                count=$(( $count + 1 ))

          ...
        done

So CRYPTTAB_TRIED here was not set to the current number of tries, but
rather to the maximum number of tries, which is 3.

So I created the attached patch, which uses $count rather than
$crypttries to initialize CRYPTTAB_TRIED.

With this patch applied, the boot process behaves correctly. When
decrypt_keyctl is called the first time for the first partition,
CRYPTTAB_TRIED is set to 0. When it is called for the first time of the
*second* partition, it is still set to 0 as for this partition it is a
first attempt and the key stored in the keyring is reused, so there is
no need to enter it a second time from the keyboard.

I have checked that entering the wrong key once also induces the script
is called a second time and the entering the proper key correctly
unlocks the partitions.

best regards,
Luc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cryptsetup.patch
Type: text/x-patch
Size: 485 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20141012/3c5776a3/attachment.bin>