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

Jonas Meurer jonas at freesources.org
Wed Oct 15 12:50:41 UTC 2014


Hey Luc,

Am 12.10.2014 um 18:33 schrieb Luc Maisonobe:
> I finally managed to understand and solve the issue (well, at least the
> following fix works for me).

Awesome, that's great news! Thanks a lot for spending your time on
debugging the issue.

> 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 far makes sense.

> 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.

Good catch. Seems like CRYPTTAB_TRIED hasn't been used too often in
initramfs so far, after all it had been set to a wrong value all the
time. And that explains why I didn't manage to reproduce the bug myself,
I only tried to unlock decrypt_keyctl devices within the cryptdisks
initscript, not within initramfs.

> 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.

Your patch looks good to me. I applied it in the cryptsetup package
repository and will upload new packages as soon as the current ones hit
testing (in a few days).

> 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.

Again, thanks a lot for your efforts!

Cheers,
 jonas



More information about the pkg-cryptsetup-devel mailing list