[pkg-cryptsetup-devel] Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files
Christoph Anton Mitterer
calestyo at scientia.net
Thu Sep 9 00:17:01 BST 2021
Oh and perhaps a bit more O:-)
The basic idea, AFAIU, would be the following, for my case:
1) The keyscript is repeatedly invoked for each device and has
CRYPTTAB_* already set (each time with the respective values).
So in that case I don't have to loop over all devices myself, nor to I
have to use anything from /lib/cryptsetup/functions .
The only exception would be, if - in my specific use case - they device
with the gpg-encrypted key file is one of those unlocked during
initramfs, in which I could end up in a deadlock.
2) For the hook the idea is, AFAIU the following:
I (!) have to loop over all the devices listed in
"$DESTDIR/cryptroot/crypttab", which had previously been populated by
the cryptoroot hook (upon which I depend).
I have no options set, but I can use crypttab_parse_options to get
them.
Then for each entry I first need to check, whether it's me (i.e.
whether the $CRYPTTAB_OPTION_keyscript is mine).
Then I can go on and parse CRYPTTAB_KEY, which in turn contains the
various options for my script.
And obviously I should e.g. do the copy_exec only once.
Does that seem about right?
Is TABFILE to be used by 3rd party hooks/keyscripts?
Or is there a better way? I've seen crypttab_foreach_entry()...
Could I use that like this:
myhook()
{
#- parses CRYPTTAB_KEY
#- set variables whether it needs to copy stuff in
}
crypttab_foreach_entry(myhook)
if [ $foo = "yes" ]; then
copy_exec whatever
fi
AFAIU, that function would also automatically detect whether it's in a
hook context, and set the right TABFILE?
Thanks,
Chris.
More information about the pkg-cryptsetup-devel
mailing list