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

[Guilhem Moulin]

Hi,

In the upcoming 2:2.0.3-5 I refactored the crypttab(5) parsing logic [0].
Would the following interface suit your needs?

    crypttab_find_entry([--quiet], $target)

        Search the crypttab(5) for the given $target and set
        CRYPTTAB_NAME, CRYPTTAB_SOURCE, CRYPTTAB_KEY, and
        CRYPTTAB_OPTIONS accordingly.  (These variables are not exported
        to the environment.)  If there are duplicates target names then
        only the first one is considered.  Return 0 if a match is found,
        and 1 otherwise.

    crypttab_foreach_entry($callback)

        Iterate through the crypttab(5) and run the given $callback for
        each entry found.  The entry currently being processed is
        refered to by the values of CRYPTTAB_{NAME,SOURCE,KEY,OPTIONS}.
        (These variables are not exported to the environment.)
        Note: $callback's return value doesn't affect the loop
        currently, but if breaking out is desired it shouldn't be hard
        to add.

    crypttab_parse_options([--export], [--quiet])

        Parse the options of a crypttab(5) mapping, defined by values of
        variables CRYPTTAB_{NAME,SOURCE,KEY,OPTIONS}, and set variables
        variables CRYPTTAB_OPTION_<option>=<value> accordingly.  These
        variables are exported to the environment if --export is set.
        Return 1 on parsing error, 0 otherwise (incl. if unknown options
        were encountered).

The crypttab(5) to use is suitably chosen depending on the context: main
system, initramfs hook scripts, or initramfs boot scripts.

See the `cryptgnupg` hook script for an example of this interface:

    https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/initramfs/hooks/cryptgnupg

I should also point out that the value of CRYPTTAB_OPTIONS is not
reliable if there are options with values containing ‘,’ characters.
So to get the value of a particular <option> one shouldn't parse
$CRYPTTAB_OPTIONS, but rather use $CRYPTTAB_OPTION_<option>.  For
instance if the crypttab(5) line being processed is

    target /dev/source none luks,header=/my/header\054swap

(minus the 4 leading spaces) then after parsing options one gets

    CRYPTTAB_NAME="target"
    CRYPTTAB_SOURCE="/dev/source"
    CRYPTTAB_KEY="none"
    CRYPTTAB_OPTIONS="luks,header=/my/header,swap"
    CRYPTTAB_OPTION_luks="yes"
    CRYPTTAB_OPTION_header="/my/header,swap"

-- 
Guilhem.

[0] https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/cb5985935713deb6bd4fd45c77d1f54cc28b204b
-------------- 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/20180706/682cfe1f/attachment.sig>