On Thu, May 12, 2011 at 12:15:48PM +0200, Axel Beckert wrote: > Package: libc0.1 > Version: 2.13-2 > Severity: important > User: [email protected] > 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 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
