[pkg-cryptsetup-devel] Several minor questions (hopefully) ;)

Mon Dec 15 23:06:13 UTC 2008

Hi Jonas.

On Mon, 2008-12-15 at 22:19 +0100, Jonas Meurer wrote:
> First, would you mind closing old and obsolete bugreport #487256? Or do
> you still regard it as a valid request?
Oh,.. I thought this was already closed... it's perfectly fine for me if
you close it,.. I have an even better solution now, which doesn't need
any changes in other places :-)

> Yes, this it's the plan to use askpass for all password prompts, and
> yes, askpass is supposed to be available both in initramfs and on the
> normal system in the future.
Good,... hopefully for both cases always in the same location ;)

> > 2) Can help functions like log_success_msg, panic, etc. also be used from
> > keyscripts, and if so from both initramdisk and normal system? (I suppose
> > not.)
> No, functions like log_sucess_msg, panic, etc. are lsb functions meant
> to be used in initscripts, and provided by /lib/lsb/init-functions.
> You're free to use /lib/lsb/init-functions for your custom scripts,
> though.

> > 3) Would it be possible to move the location from the keyscripts within the
> > iniramdisk to the same location as in the normal system? I mean from
> > /keyscripts/ to /lib/cryptsetup/scripts/. Would be more consistent IMHO,
> > and might be of advantage when you look for these files from other scripts
> > or so.
> I think that the initial reason to change the keyscript diretory was
> that the initramfs is meant to be as small as possible, and some extra bytes
> for deeper directory structures as well as longer pathnames already do make
> a difference here. Not sure about that one though.
*g* Ok... perhaps we can ask David about this,... I think the way we're
creating our initramdisk images is already very generous (I think we
depend on busybox, on the keyboard mapping, and IIRC we include "most"
cipher modules, righ?) so it's probably not worth looking at these few
bytes we save by that....

Anyway this isn't a big problem for me, I just thought it would be
cleaner to use the same location in both cases. Actually I've just
started thinking about it because of 4) ;)

> Yes, that's correct. I fixed cryptdisks.functions to search for the
> given keyscript in /lib/cryptsetup/scripts now.
Ah thanks :-)

> The mountdev.c keyscript was written by David Härdeman. He later renamed
> it to passdev.c and obviously forgot to update the cryptpassdev
> initramfs hook. I fixed it now. Thanks for pointing that out.
Thanks again :-)

Apropos passdev: I've read the source and I'd have two ideas for
improvement ;)
1) Some of the messages written to stderr are lacking "\n" in the end
(these are probably minor typos). Could you please fix this?

2) Currently the script tries to mount <device> somewhere and then read
<path>. It could easily happen that device is already mounted, but then
the whole thing fails.
It would be great if passdev recognizes this and then bind-mount (of
course also ro). (btw: I don't know if this works, when the original
mount was rw).

This would allow use to use passdev more generically,...
e.g. I'm using passdev from within my new versions of decrypt_open,...
but right now I have to check whether the key-file-parameter contains a
colon and depending on that use either passdev or not.

That way we could extend the key-file-option in crypttab to generally
allow either device:path or just path . I'd do the work and modify the
existing decrypt_scripts to use passdev.

And then it would also be interesting to think whether passdev should be
automatically added via the cryptroot hook, currently I'm doing this via
a separate hook that checks whether decrypt_openpgp is used and if so,
adds the dependencies to initrd.

> Sorry, I don't know the proper answer for that question. I doubt that a
> "best way" even exists. There are dozens of ways to set defaults for
> dozens of different situations. If the gnupg default is stored inside a
> file in /etc/defaults, then you should use that one.
Hmm ok,.. think I've shipped around this anyway,.. you'll see once I'm
finished :-)

> > 7) What are the duties of a keyscript? Is it just plain decrypting and
> > reporting whether this was successful (exit 0) or not (exit 1) or also
> > retries, timeouts, etc? Or is this handled "above"?
> That's something to be yet decided. I just completely removed support
> for timeouts from cryptdisks initscripts, and initramfs never even
> supported it.
Oh :-( how sad... shouldn't this be quite easy to implement? e.g. using
a timeout script when running the keyscript?

> retries is meant to be used for passphrase input prompts
> only.
Ok but in that case I would be necessary to support it from inside the
keyscripts, right?
e.g. if my gnupg decryption fails,.. I'd have to repeat it.

> It doesn't make sense to use either for keyfiles, and it's not decided
> yet what to do about keyscripts.
We'll I think some mechanism for retries is definitely needed for
keyscripts,.. (see my gpg example)

> Currently keyscripts are invoked $tries times in case that they file,
> but as keyscripts may do any kind of keyfile and/or passphrase
> processing, one could argue that supporting retries on a higher level
> might be as useless as for keyfiles.
Yes,... that's true...
Currently I rely with my decrypt_openpgp that the keyscript is simply
invoked tries-times.
If you change this,.. you'd have to provide tries a 2nd and perhaps
timeout as 3rd parameter.

> So after all I tend to say that keyscripts need to provide retries
> support on their own in case that they depend on passphrase input.
I'd also prefer this,... perhaps the same for timeouts.
Well,.. if the timeout and/or tries are _not_ managed via the keyscript
we are sure that it will always work,.. however we cannot add
improvements, e.g. it might not be necessarry to do everything in the
keyscript again (like in my case using passdev).

So I'd suggest the following: tries should be managed by the keyscripts
(and they get the number via 2nd parameter)
but timeout shouldn't be managed by the keyscripts,.. a timeout is
anyway always a hard border,... once it's reaced,.. party over.

Thanks,
Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5108 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20081216/84bd0792/attachment.bin 