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

[debian at x.ray.net]

hi!

> This sounds like an interesting approach. As I got from #465901, this
> will enable dropbear per default if cryptroot is detected. While I like
> the idea to be able to enable ssh support for initramfs, I object
> against this default behaviour. Not everyone with cryptroot is in need
> of remote access during boot process. Thus I suggest to disable the
> whole feature per default, and make it configurable in any case.

ok. not my preference, but i understand the rationale.
this behaviour is implemented in the dropbear patch. i guess the 
dropbear maintainer will read the related initramfs-tools and this 
report, and i will submit a patch with the always-no-default if he 
requests so.

> Also, please resend the patch in unified format (diff -rNu).

ok.

>> 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.
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.
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).

	Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cryptsetup_2:1.0.6~pre1-1.x.unified.diff
Type: text/x-patch
Size: 1807 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20080216/ea41f4a2/attachment.bin