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

[luc]

Le 2014-10-08 23:21, Jonas Meurer a écrit :
> Hey Luc,

Hi Jonas,

> 
> Am 03.10.2014 um 21:55 schrieb Jonas Meurer:
>> Am 03.10.2014 um 21:15 schrieb Luc Maisonobe:
>>>> I failed to reproduce the bug you discovered so far. Can you please 
>>>> give
>>>> the latest packages from
>>>> https://people.debian.org/~mejo/debian/mejo-unstable/ a try and see
>>>> whether decrypt_keyctl still doesn't work for you?
>>> 
>>> The new packages allow to boot, but I still have to enter the key 
>>> twice,
>>> once for each encrypted device.
>> 
>> Very strange. I'm still unable to reproduce the issues you encounter.
>> Could you do some futher testing for me?
> 
> Did you find time to do the additional testing/debugging yet? I'd like
> to fix this bug in time for Debian Jessie, provided that it's really a
> bug in the package and not an issue on your side ;)

Not yet, but I intend to do so.
The problem occurs on a computer with some critical information on it,
and the partitions already use the full disk space. This implies I have 
to do
some careful work of shrinking filesystems, logical volumes and so on 
before I can
set up a test partition aside.

> 
> As already mentioned - up to now I'm unable to reproduce the bug. For
> me, decrypt_keyctl works in all tested setups. The provided passphrase
> is stored in kernel keyring with first invokation and used for all the
> following device unlockings that have the same keyscript/keyname 
> configured.

I understand your point. It is difficult to debug here (as mentioned 
earlier putting
some echo commands completely trashed the boot sequence). I'll do my 
best.

best regards,
Luc

> 
> Kind regards,
>  jonas
> 
>> I test the decrypt_keyctl script with the following setup, and it 
>> works
>> as expected. Maybe you could try a similar setup:
>> 
>> - create two small lvm logical volumes (5MB are more than enough)
>> - luksformat both logical volumes
>> - add them to your crypttab:
>> 
>> clv1_crypt /dev/<VG>/<LV1> testkey1 luks,keyscript=decrypt_keyctl
>> clv2_crypt /dev/<VG>/<LV2> testkey1 luks,keyscript=decrypt_keyctl
>> 
>> - try unlocking them via cryptdisks_start:
>> 
>> # cryptdisks_start clv1_crypt
>> # cryptdisks_start clv2_crypt
>> 
>> The second unlocking should use the key cached during first unlocking.
>> 
>> It would be awesome if you could test this. I as well tested this 
>> setup
>> during boot process, and it works as expected as well. Also tested 
>> with
>> UUID instead of source device path in crypttab, same result.
>> 
>> I've no glue what's different on your setups, and any help with
>> debugging would be highly appreciated.
>> 
>>>> In case that you still encounter the bug, please paste your full
>>>> /etc/fstab and /etc/crypttab again.
>>> 
>>> /etc/crypttab:
>>> 
>>> sdb1_crypt UUID=9aa983b5-0224-406b-a177-7481162c6172
>>> sda5_sdb1_common_key luks,keyscript=decrypt_keyctl
>>> sda5_crypt UUID=3764df68-de26-4a24-a7dc-1498cb6b20ab
>>> sda5_sdb1_common_key luks,keyscript=decrypt_keyctl
>> 
>> Nothing suspicious here, looks ok to me.
>> 
>>> Note that the two partitions contain physical volumes for LVM, as 
>>> shown
>>> here:
>> 
>> Actually the content of your encrypted devices should not matter at 
>> all.
>> 
>> Kind regards,
>>  jonas
>> 
>> _______________________________________________
>> pkg-cryptsetup-devel mailing list
>> pkg-cryptsetup-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel
>>