On Sun, 1 Nov 2009 12:10:43 +0000 Neil Williams <codehelp@debian.org> 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/
Attachment:
pgpb8L_KcNdmx.pgp
Description: PGP signature