[PATCH 1/7] binman: Fix unique names having '/.' for images read from files

[Simon Glass]

On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>
> Binman can embed a copy of the image description into the images it
> builds as a fdtmap entry, but it omits the /binman/<image-name> prefix
> from the node paths while doing so. When reading an already-built image
> file, entries are reconstructed using this fdtmap and their associated
> nodes still lack that prefix.
>
> Some entries like fit and vblock create intermediate files whose names
> are based on an entry unique name. This name is constructed from their
> node's path by concatenating the parents with dots up to the binman
> node, e.g. /binman/image/foo/bar becomes 'image.foo.bar'.
>
> However, we don't have this /binman/image prefix when replacing entries
> in such an image. The /foo/bar entry we read when doing so erroneously
> has the unique name of '/.foo.bar', causing permission errors when the
> entry attempts to create files based on that.
>
> Fix the unique-name generation by stopping at the '/' node like how it
> stops at the binman node. As the unique names are used as filenames, add
> tests that check if they're safe to use as filenames.
>
> Signed-off-by: Alper Nebi Yasak <alpernebiyasak at gmail.com>
> ---
>
>  tools/binman/entry.py                        |  2 +-
>  tools/binman/ftest.py                        | 31 ++++++++++++++++
>  tools/binman/test/230_unique_names.dts       | 34 ++++++++++++++++++
>  tools/binman/test/231_unique_names_multi.dts | 38 ++++++++++++++++++++
>  4 files changed, 104 insertions(+), 1 deletion(-)
>  create mode 100644 tools/binman/test/230_unique_names.dts
>  create mode 100644 tools/binman/test/231_unique_names_multi.dts

Reviewed-by: Simon Glass <sjg at chromium.org>