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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
