Hi Jonas, Le 09/10/2014 10:39, Jonas Meurer a écrit : > Hey Luc, > > Am 09.10.2014 um 09:54 schrieb luc: >>> Am 03.10.2014 um 21:55 schrieb Jonas Meurer: >>> 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. > > I see. But you don't need to resize your filesystems or go through > similar hassle. Simply use file containers for testing. The following > commands should setup a testing environment (use carefully, even though > I tested them): > > # dd if=/dev/urandom of=/cont1 bs=1M count=3 > # dd if=/dev/urandom of=/cont2 bs=1M count=3 > # echo "testpw" | cryptsetup luksFormat /cont1 > # echo "testpw" | cryptsetup luksFormat /cont2 > # echo "cont1_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl" \ > >> /etc/crypttab > # echo "cont2_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl" \ > >> /etc/crypttab > # cryptdisks_start cont1_crypt > # cryptdisks_start cont2_crypt
On the first invocation (for cont1_crypt), I got this dialog: root@marislae:~# cryptdisks_start cont1_crypt [[....] Starting crypto disk...[info] cont1_crypt (starting)... Caching passphrase for /cont1: ****** keyctl_set_timeout: Permission denied Error setting timeout on key (2524288), removing Caching passphrase for /cont1: ****** keyctl_set_timeout: Permission denied Error setting timeout on key (612589418), removing [Here I pressed <ctrl-C> to stop the attempts] Caching passphrase for /cont1: Erreur de lecture de la phrase secrète. I was running the commands from root. I initially logged in to the computer from SSH to a regular user, than did "sudo -i" to get root access if this matters. As I suspected this may be a problem, I allowed root direct SSH access and tried again, login directly to root account, this time it worked: root@marislae:~# cryptdisks_start cont1_crypt [....] Starting crypto disk...[info] cont1_crypt (starting)... Caching passphrase for /cont1: ****** [ ok _crypt (started)...done. root@marislae:~# cryptdisks_start cont2_crypt [....] Starting crypto disk...[info] cont2_crypt (starting)... Using cached passphrase for /cont2. [ ok _crypt (started)...done. root@marislae:~# The /dev/mapper/cont1_crypt and /dev/mapper/cont2_crypt did appear correctly. Is there a way I could check the keyring just after boot, before it is cleared? I could probably set an independent init script to run after disks are mounted to dump the list of the keys in the keyring to some file in /tmp so I can retrieve them once the system is up and debug. I thing I could do this using some keyctl command, but don't know which one to use for a given entry in /etc/crypttab. Should it be simply "keyctl list pw1" in the case of your example or something else? I saw in the decrypt_keyctl script some cryptkey-$1 identifier (probably used with an _ appended). How could I use this? best regards Luc > >>> 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. > > I'm sorry that I brought you in troubles here. The echo command was > untested and I at least should have written that. It was meant for > debugging purposes only but it completely broke the keyscript. I'll try > to not make such premature requests again :-/ > > Cheers, > 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-de...@lists.alioth.debian.org >>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel >>>> >>>> >> >> _______________________________________________ >> pkg-cryptsetup-devel mailing list >> pkg-cryptsetup-de...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org