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

[Jonas Meurer]

On 20/02/2008 debian at x.ray.net wrote:
> hi!
>
>> 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.
>
> it looks like this was simply because of the stdin redirection for the  
> read, changing the std* of the processes inside the loop therefore looks  
> like collateral damage and the < /dev/console > /dev/console like a  
> workaround, which the construct according to the diff simply fixes.
>
> i hope david will point it out in case there is any additional knack to it.

David, can you comment on this. I have to admit that I don't understand
the initramfs stuff good enough yet to make a decision regarding this
bugreport.

>> That would mean to have a 'killall cryptsetup' at the end of every
>> cryptroot execution.
>
> right. i think that's ok.

Not sure. It's ok in a common setup, but what about users who use custom
scripts in their initrd which invoke cryptsetup as well. sure, sounds
like a corner case, but I still don't like the idea to kill every
cryptsetup process per default in cryptroot initramfs script.

>> 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.
>
> i beleive that it's really a good idea not to duplicate code, even more  
> so as the aim is to do the identical thing from a shell.
>
> the bootsplash code is actually untouched and it doesn't seem to use the  
> tty - currently it has none anyway, just a stdin redirection which it  
> doesn't use.
>
> comparing the options of having to take care that tty independent code  
> does not interfere with bootsplash code or that it gets the correct  
> redirects if it needs any, to copying the cryptroot script to  
> cryptunlock and removing cryptkey and bootsplash specific parts from  
> this copy, i'd really say i'm convinced the first is the way to go.

I don't think that it is needed to copy the cryptroot script to
cryptunlock.

> generally, removing the explicit redirects doesn't change the behaviour  
> when called during the boot process, stdin and stdout will still be  
> /dev/console. the difference is just that it won't break when called  
> with a different tty.
>
> again, if there's a missing point, i hope david will point it out.

I see your point, but I still believe that david had something in mind
when he introduced that redirection, so I would rather wait on his
comment.

> i hope i was able to resolve the issue of possible problems of the  
> redirection modifications.
>
> i made a new patch that also makes sure that the bootsplash part is done  
> only in the boot process' instance.
>
>>>> 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?
>
> in the case that the standard cryptsetup call is done by the  
> cryptkeyscript code, the standard cryptsetup call will be  
> unused/superfluous (plus probably a cryptkeyscript had to be added that  
> provides the input from the console/tty).

That's why david suggested to use a fifo. The keyscript is executed
before invoking cryptsetup, and it would read the key from the fifo file
when it's given to cryptunlock. afterwards the cryptroot script takes
the output of the keyscript as key for cryptsetup.

Another way I can think of is a keyscript simply waiting for some file
/tmp/<crypttarget>-key to exist. As soon as this file exists, it passes
is as key to cryptsetup.
The cryptunlock script would take the part to create and fill this
script.

greetings,
 jonas