Bug#626482: libc0.1: 2.13 causes segfaults + bus errors inside DSA's dchroots on kfreebsd-*
On Thu, May 12, 2011 at 12:15:48PM +0200, Axel Beckert wrote:
> Package: libc0.1
> Version: 2.13-2
> Severity: important
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
>
> [Mostly a summary of
> http://lists.debian.org/debian-bsd/2011/05/msg00038.html and
> http://lists.debian.org/debian-bsd/2011/05/msg00039.html]
>
> After dist-upgrading libc0.1 and friends (i.e. all(*) installed packages
> which are also built from eglibc source) from 2.11.2-something to 2.13-2
> inside io's and asdfasdf's sid, calling "dchroot sid" segfaults on io
> and causes bus errors on asdfasdf:
>
> io:~# dchroot sid /bin/true
> Segmentation fault
> io:~# dchroot sid
> Segmentation fault
> io:~#
>
> asdfasdf:~# dchroot sid /bin/true
> Bus error
> asdfasdf:~# dchroot sid
> Bus error
> asdfasdf:~#
>
> Ah normal (but root only) "chroot /srv/chroot/sid" works on both
> machines, so I could at least fix it from the inside by downgrading
> libc0.1 and friends back to 2.11.2-13.
>
> Please note that the used dchroot command comes from DSA's version of
> dchroot-dsa (version 2:1.1), not from the one in the Debian archive. The
> latter does not show this problem according to Petr Salinger.
>
> I'm not sure where exactly the causing bug is located, it could be in
> eglibc, in DSA's dchroot, and maybe also in gcc-4.6 (with which libc0.1
> 2.13-2 very likely has been compiled). But as downgrading libc0.1 and
> friends helped to fix this regression, I'm filing it against libc0.1.
>
> I'm not filing this as RC as it is not yet reproducible with only
> packages from the official archive, but since porterboxes are affected
> I doubt that this is a less important issue.
First of all please note that this problem is not GNU/kFreeBSD specific, but
can easily reproduced on GNU/Linux.
The problems comes from the fact that dchroot calls chroot() to actually
chroot into a directory, and after calls libc functions which can
trigger library loading. It means that the version of the library in the
chroot will end-up in the same memory space that libraries inside the
chroot, and they might not be compatible. In our case, the call to
initgroups() after chroot() might load libnss-db from the chroot
(depending on some conditions, mainly if the user is defined in
/etc/passwd or in the nss database inside and outside the chroot), and
libnss-db as most libnss libraries has a strong dependency on the libc
version.
> So feel free to raise the severity and/or reassign this bug.
>
IMHO the bug is in dchroot-dsa, but given the version we are using is
not in the archive, I can't reassign it.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: