[pkg-cryptsetup-devel] Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Guilhem Moulin]

On Sat, 11 Sep 2021 at 01:31:31 +0200, Christoph Anton Mitterer wrote:
> I mean in a keyscript, CRYPTTAB_* are anyway already set for the
> "current" target, right?
> And in a initramfs hook, I anyway need to loop over all of them... or
> at least I wouldn't have a particular (target) name to search for?

Right.

> 2) crypttab_foreach_entry()
> That's what I'd use in the hook. But you've mentioned that the
> callbacks return value is ignored.
> Could that be changed perhaps?

If desired, yes.

> In my case it's probably not a big deal:
> - if the callback would find that the "current" entry isn't meant for
>  "my" script, then it could just return without doing anything
> - if however an error occurs (e.g. no pathname= set) it would anyway
>  just exit 1 the whole hook, since it's "catatrophic" failure and an
>  initramfs level device couldn't be unlocked

Right, that's what we're doing too.

> Also in crypttab_foreach_entry(), do I already have CRYPTTAB_OPTION_*?
> Or really just the four CRYPTTAB_{NAME,SOURCE,KEY,OPTIONS} and I need
> to call crypttab_parse_options to get the split up ones?

You need to call crypttab_parse_options() in the callback, see the
cryptgnupg keyscript for an example.  IIRC this is intentional because
te callback need to have the ability to bail out before option
validation.
 
> But in keyscripts I would already have CRYPTTAB_OPTION_*, too, right?

That's what's documented in crypttab(5).

> 3) Escaping
> My understanding is, that in both, the keyscript and the hook (when
> using e.g. crypttab_foreach_entry()) any CRYPTTAB_* is already
> unescaped, right?

Yes.  FWIW the original unescaped values can be found in _CRYPTTAB_*,
but this is undocumented and thus may not be relied upon.

> You also mention above, that CRYPTTAB_OPTIONS is not safe to use, when
> values contain ",".
> I assume this is because, the unescaped CRYPTTAB_OPTIONS would contain
> both, the "," from the values and the "," from the separators?
> While CRYPTTAB_OPTION_* would take care of that properly?

Correct.

> For which fields are the octal escapes handled? The manpage only
> mentions them for them for the key/3rd field.

My bad, it's supported in all fields.

> 4) Wishlist ;-)
> Can we have something like the option splitting for the key/3rd field,
> too?

That's too much a niche case IMHO.  When you use a key script the 3rd
field is an opaque value passed along and you might treat it any way you
see fit.

> In the end,... and you'll probably not like it ^^ ... I'd even suggest
> to rename the 3rd filed to something more generic... just KEY or
> KEYOPTIONS or so.

That would have have been a valid suggestion at the time the interface
was designed, but many releases later I'm afraid renaming is not an
option.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20210911/8ac6ccea/attachment.sig>