Bug#888106: initramfs-tools: mkinitramfs should fail when ldd fails in copy_exec

[Trek]

On 23 Jan 2018 13:49:30 +0100
Andrew Shadura  wrote:

> The return code of ldd is not handled at all. Should ldd fail for any
> reason, this failure will be ignored.

with this code, failures of ldd should be handled

  ldd_output=$(ldd "${src}" 2>/dev/null) || return $?
  for x in $(echo "$ldd_output" | sed -e …)
  do
  done


the problem is when copy_exec is used to copy script files, for
example as cryptsetup does to copy the keyscripts

it can be solved in two ways:

1) check if ldd is running fine at the start of mkinitramfs
   ldd /bin/sh >/dev/null || exit $?

2) handle ldd errors and change packages to use copy_file instead of
   copy_exec when copying files other than binaries


ciao!

Bug#888106: initramfs-tools: mkinitramfs should fail when ldd fails in copy_exec

[Andrew Shadura]

Package: initramfs-tools
Version: 0.130
Severity: minor

Dear Maintainer,

We're working on a minimalist build of a Debian derivative which doesn't
include bash, and we ran into an situation in which due to a human error
the system didn't have a working ldd. This wasn't detected during an
image build process as mkinitramfs happily ignored ldd not working
(while being present and being an executable), and proceeded creating
a broken initramfs. In hook-functions, copy_exec does the following:

# Copy the dependant libraries
for x in $(ldd "${src}" 2>/dev/null | sed -e …)
do
done

The return code of ldd is not handled at all. Should ldd fail for any
reason, this failure will be ignored.

I tried to write a patch, but I couldn't come up with an elegant
solution which would cover cases other than just a wrong hashbang in
ldd :)

Maybe something like https://www.spinics.net/lists/dash/msg00165.html
can be used, but it's up to you to introduce hacks like that into the
code.

Thanks in advance.

-- 
Cheers,
  Andrew