[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature

[Jonas Meurer]

Hey Chris,

On 16/02/2008 debian at x.ray.net wrote:
>>> in the initramfs scripts, the target might be unlocked (from remote) 
>>> in  the background. so on non-successful cryptsetup exit, check 
>>> whether the  target is unlocked, only otherwise act on it as a 
>>> failure.
>>> for this unlocking in the background (and if successful, killing the  
>>> waiting cryptsetup), the cryptcreate script is added.
>>> to call this unlocking script from remote, dropbear has to be added 
>>> to  the initramfs, so dropbear is added to the suggested list.
>>
>> I have to admit that I don't get that. In your patch, a script
>> /sbin/cryptcreate is created, which itself uses the variables
>> $cryptcreate and $crypttarget. This script is made executable, but I
>> cannot find the place where it actually is executed. Also, how does the
>> script know about the variables used by it?
>
> the idea is that when the boot process is waiting at the passphrase  
> prompt, it is possible to log in via ssh and manually call a script  
> which prompts for the passphrase, and in case the passphrase is correct  
> and the root-fs is unlocked, kills the process waiting at the console,  
> so the boot process continues.

Ok, so the script will be executed by the initramfs script provided by
dropbear? 

> i admit that the name 'cryptcreate' for this script is quite  
> unintuitive, so i changed that in the attached new, unified diff: the  
> script's name is now 'unlock' - i hope this is more intuitive.

I think that cryptunlock is even more intuitive ;-) Would you accept
this name as well?

> the variables will be expanded when the script is written, and as  
> $cryptcreate is already used to store the cryptsetup call, this seemed  
> to me to be the most straightforward way to guarantee that the  
> cryptsetup call to unlock the cryptroot from the shell is identical to  
> the cryptsetup call at the console (and likewise the two crypttarget  
> tests should always test the identical target).

Sure, you're right ;-) Thanks for explanation, and sorry for confusion.

greetings,
 jonas