"Packages with absolute symlinks to dirs like libc6 on amd64, ppc64 and
s390x can lead to overwrites of files outside of the new root."
dpkg also suffers the same problem on 'dpkg -e' (#514702)
and therefore multistrap too:
neil@holly:debootstrap$ ls -lh multistrap/test/lib64
lrwxrwxrwx 1 root root 4 2009-03-22 15:53 multistrap/test/lib64 -> /lib
(multistrap/test is the chroot and the link is clearly to the /lib
outside the chroot directory, not ./lib inside.)
It only affects writes during the multistrap process itself, once
inside the chroot, writes remain within the chroot:
neil@holly:debootstrap$ sudo chroot multistrap/test
root@holly:/# touch /lib64/foo
root@holly:/# exit
neil@holly:debootstrap$ ls /lib/foo
ls: cannot access /lib/foo: No such file or directory
neil@holly:debootstrap$ ls multistrap/test/lib/foo
multistrap/test/lib/foo
So the problem isn't necessarily that the links exist in the packages,
it's that the unpacking process in each case follows the symlink.
Possible test:
$ sudo find -L . -xtype l -type d -exec ls -l '{}' \; 2>/dev/null|sed 's/.* \.\(.*\)> \(.*\)/\1> \2/'|grep -e "> /"
/dev/fd -> /proc/self/fd
/lib64 -> /lib
One problem for multistrap is that it is specifically designed for
cross-architecture work, so multistrap itself cannot use chroot as a
wrapper around the unpack routines.
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:
neil@holly:test$ ls -ld lib64
lrwxrwxrwx 1 root root 5 2009-11-01 11:07 lib64 -> ./lib
neil@holly:test$ sudo dpkg -e /var/cache/apt/archives/libc6_2.10.1-3_amd64.deb ./
neil@holly:test$ ls -ld lib64
lrwxrwxrwx 1 root root 5 2009-11-01 11:07 lib64 -> ./lib
./lib64 now has different contents to /lib64.
neil@holly:test$ ls /lib64/foo
ls: cannot access /lib64/foo: No such file or directory
neil@holly:test$ ls ./lib64/foo
./lib64/foo
neil@holly:test$ sudo chroot .
root@holly:/# ls /lib64/foo
/lib64/foo
(from the earlier test)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpRfVSUShp8o.pgp
Description: PGP signature