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

[debian at x.ray.net]

hi!

jonas wrote:
> The cryptunlock script will be recreated for every dm-crypt target that
> uses a passphrase. In other words, cryptunlock has to be invoked for
> every required passphrase. Am I correct here?

yes you are, and that made me realize that i totally ignored the
multiple crypt targets scenario...

the cryptunlock script ofc has to go through all targets, too. actually
it would in the end have to do more or less the full cryptroot-script
run plus killing the console cryptroot-script after it completed. so
that means it's most straightforward to simply call the cryptroot-script
(and change this to work with random ttys).

as the current rationale is to continue with the boot process after all 
targets were handled (and not necessarily successfully unlocked, which 
can make sense if some of them are not vital for booting), a check that 
all targets are unlocked is not needed.

i guess simply killing all cryptsetups is ok. so adding that killall to 
the cryptroot-script should make another script superfluous.

so, now the command to unlock the crypttargets after logging in via
dropbear, is simply /scripts/local-top/cryptroot itself.

david wrote:
> If you want both, it could still be done as a keyscript. Let the
> keyscript do the prompt and wait for user input, meanwhile the script

this means in this case the non-keyscript cryptsetup part from
cryptroot-script should consequently be removed?

> could also create a fifo and wait for input of a passphrase via that
> fifo in parallel.
>
> It might be harder to implement as a shell script...but it should be
> doable...something like "echo some_prompt > /dev/stdout; mkfifo
> /tmp/cryptpass; cat /dev/stdin /tmp/cryptpass | read REPLY" (haven't
> tested it so I can't be sure it works).

i don't think that will work...
i don't have any idea right now how this could be achieved in a simple
.sh way... (see 'console in screen or similar'...)

> The advantage is that there is no need to kill cryptsetup processes

not having to kill a cryptsetup process would certainly be an advantage.
but after all i'd still say extending the non-keyscript functionality is
more straightforward.

> and no need to change cryptsetup initramfs scripts. The keyscript

i think the non-keyscript cryptsetup part had to be removed (plus 
probably a non-keyscript cryptsetup script had to be added).

> could also write the name of the device it is currently waiting for a
> passphrase for to some file which the cryptunlock util could read so
> that it can provide a more user friendly prompt.

well that touches the point which jonas pointed out earlier, i totally
missed the multiple-crypttargets scenario...
i think that's fixed nicely.

above the (1st try's) prompt-line, the info about the target to be 
unlocked should be printed.

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