[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature
jonas at freesources.org
Sat Feb 16 16:22:30 UTC 2008
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
>>> 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
> 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.
More information about the Pkg-cryptsetup-devel