On Sun, 1 Nov 2009 12:10:43 +0000 Neil Williams <[email protected]> wrote:
> A simple check appears sufficient, from outside the chroot, prior to
> unpacking:
>
> #!/usr/bin/perl
> $dir = "/path/to/top/of/chroot/"
>
> if (-l "${dir}lib64" ) {
> $r = readlink "${dir}lib64";
> if ($r =~ m:^/:)
> {
> my $old = `pwd`;
> chomp ($old);
> unlink "${dir}lib64";
> chdir ("$dir");
> symlink "./lib", "lib64";
> chdir ("$old");
> }
> }
>
> (The chdir is necessary, it needs to be lib64 -> ./lib not lib64
> -> /path/to/chroot/lib otherwise chroot fails to execute /bin/bash but
> that's just a side-effect of using the perl symlink function instead
> of calling ln directly.)
>
> Possibly run the find test too, just to catch any new cases.
>
> Thankfully, dpkg -e doesn't clobber this fix:
Actually, it does in actual usage - the test is unpacking over the top
of an existing unpacked package. When it's the first unpacking, dpkg
(or tar) removes the pre-existing symlink.
This makes the multistrap patch more complex but it does now work.
Until the other bug in dpkg/tar/libc6 is fixed, you may see this in the
multistrap output:
I: Extracting libc6_2.7-18_amd64.deb...
-> Processing conffiles for libc6
ERR: lib64 -> ./lib symbolic link clobbered by libc6
INF: lib64 -> /lib symbolic link reset to ./lib.
from version 2.0.4 onwards.
The check is done immediately after unpacking each package.
If, for some reason, the symlink is still bad at the end, multistrap
will warn you:
ERR: ./lib64 -> /lib symbolic link reset to ./lib after unpacking.
ERR: Some files may have been unpacked outside $dir!
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpYjMJMVrs0x.pgp
Description: PGP signature
