[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature
debian at x.ray.net
debian at x.ray.net
Wed Feb 20 15:02:25 UTC 2008
> I object against this. At least I believe that David had something in
> mind when he added the '< /dev/console >' redirections to invocations of
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
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:
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
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2976 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20080220/355c9439/attachment.bin
More information about the Pkg-cryptsetup-devel