Hello,
On Thu, Nov 08, 2012 at 09:51:57AM +0100, Helmut Grohne wrote:
> So I had a further look into the dropbear initramfs issue. The code
> where the breakage occurs is dropbear's hook:
>
> | LIBC_DIR=$(ldd /usr/sbin/dropbear | sed -n -e 's,.* =>
> \(/lib.*\)/libc\.so\..*,\1,p')
> | for so in $(find "${LIBC_DIR}" -name 'libnss_compat*'); do
> | copy_exec "${so}" "${LIBC_DIR}"
> | done
>
> The error lies in the innocent looking copy_exec line. The target is a
> directory here, but the documentation of copy_exec says it should be a
> file:
>
> | # $1 = file to copy to ramdisk
> | # $2 (optional) Name for the file on the ramdisk
> | # Location of the image dir is assumed to be $DESTDIR
> | # We never overwrite the target if it exists.
> | copy_exec() {
>
> So if the target directory happens to not exist which is the case for
> LIBC_DIR=/lib/i386-linux-gnu/i686/cmov in my case, the source will be
> copied to that name. So "cmov" ends up being a regular file and not a
> directory containing the file.
>
> Now really whose bug is this? Let us have a look at other users that
> pass a second parameter to copy_exec.
>
> Those that pass a directory:
> /usr/share/initramfs-tools/hooks/keymap:copy_exec /bin/loadkeys /bin
> /usr/share/initramfs-tools/hooks/keymap: copy_exec /usr/bin/kbd_mode
> /bin
> /usr/share/initramfs-tools/hooks/dropbear: copy_exec
> "/usr/sbin/dropbear" "/sbin/"
> /usr/share/initramfs-tools/hooks/dropbear: copy_exec
> "${so}" "${LIBC_DIR}"
> /usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/udevd /sbin
> /usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/udevadm /sbin
> /usr/share/initramfs-tools/hooks/udev: copy_exec /lib/udev/$program /lib/udev
> /usr/share/initramfs-tools/hooks/udev:copy_exec /sbin/blkid /sbin
> /usr/share/initramfs-tools/hooks/udev: copy_exec /lib/udev/vio_type /lib/udev
> /usr/share/initramfs-tools/hooks/mdadm:copy_exec $MDADM /sbin
> /usr/share/initramfs-tools/hooks/cryptroot:
> copy_exec "/lib/cryptsetup/scripts/$KEYSCRIPT" /lib/cryptsetup/scripts >&2
> /usr/share/initramfs-tools/hooks/cryptroot:
> copy_exec "$KEYSCRIPT" /lib/cryptsetup/scripts >&2
> /usr/share/initramfs-tools/hooks/cryptroot:
> copy_exec "${KSTYPE#"$KEYSCRIPT" is }" /lib/cryptsetup/scripts >&2
>
> The one gets it right:
> /usr/share/initramfs-tools/hooks/busybox: copy_exec
> ${BUSYBOXDIR}/busybox /bin/busybox
>
> It seems like most users actually get this wrong. Out of sheer (bad)
> luck this has not been discovered thus far.
>
> How do we proceed now? The current API of copy_exec is bad, because it
> relies on auxiliary state (the target being a directory or not). It
So copy_exec behaves like cp(1). Maybe introduce a warning for wheezy if
the 2nd argument is a directory in /? This isn't 100% fail-safe but
should catch most cases (among them all of the above instances).
Maybe also keep the cp semantics for copy_exec and only warn in the
failing cases? (i.e. test -d "$2" && test ! -d "$pathtoinitramfs/$2")
Best regards
Uwe
> should be fixed, but this is likely too late for wheezy, given the
> number of packages that need to be changed as well.
>
> The particular dropbear issue can be avoided by actually omitting the
> second parameter and letting copy_exec sort it out correctly. I believe
> that this change should fix both bugs #682964 and #630581.
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121108091358.gk27...@pengutronix.de
