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

[Jonas Meurer]

On 18/02/2008 debian at x.ray.net wrote:
> 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).

I object against this. At least I believe that David had something in
mind when he added the '< /dev/console >' redirections to invocations of
cryptsetup.

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

That would mean to have a 'killall cryptsetup' at the end of every
cryptroot execution.

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

I don't like the idea to use the initramfs cryptroot script for that. If
other bootsplash system need to be supported in furture, this could lead
to major problems. I believe that redirect of stdout and stdin to
/dev/console already is necessary to support usplash. But i'm not sure
about that one. David might know more.

> 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?

I would prefer that solution as well, yes.

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

Why not try exactly what David suggested? Create a FIFO file in the
keyscript, read that FIFO until a passphrase has been submitted, and
deliver that to cryptsetup afterwards. The FIFO then will be filled with
the passphrase by some script that the user invokes from the dropbear
login.

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

I don't think so. At least not if that means to change initramfs scripts
in a way that could cause problems later.

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

what do you mean here?

greetings,
 jonas