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

[debian at x.ray.net]

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.

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

right. i think that's ok.

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

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.

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

well although the problem is obvious, i actually even did. you can just 
try it yourself:

cat /dev/stdin /etc/passwd

passwd will not be shown until you pass an EOF from stdin. this also 
works the same when using a fifo.

this means if you boot, and a password is entered from remote via shell 
(into the fifo), nothing will happen until you enter an EOF at the 
console. if you enter a password at the console, you will have to send 
an extra EOF afterwards. and if somebody enters a password from the 
shell, and you entered a password at the console and sent an EOF, the 
result will be a wrong password. ok, you could do one funny thing with 
it, the person at the console could enter the first part of the 
password, and the person at the shell could enter the rest of the 
password (like a lock requiring two keys - but both of them could easily 
intercept the other person's password-part, plus the person at the 
console had to wait until the person at the shell definitely finished 
before sending the EOF)...

maybe you would prefer something like this:

mkfifo /tmp/foo
cryptsetup </tmp/foo &
cat - >/tmp/foo

in this case, filling the fifo is non-atomic, the console and the shell 
inputs could interfere. waiting for cryptsetup to finish, as well as 
getting the result of cryptsetup back is non-trivial. in cases of 
failures there is a risk of cryptsetups dangling in the background, 
messing with things done in the foreground.

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

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

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