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.
signature.asc
Description: PGP signature
