Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd
On Sat, Nov 15, 2014 at 02:07:44PM +0100, Aurelien Jarno wrote:
> On Mon, Nov 11, 2013 at 10:23:25AM +0100, Laurent Bigonville wrote:
> > Le Mon, 11 Nov 2013 09:40:52 +0100,
> > Sven Hartge <sven@svenhartge.de> a écrit :
> >
> > > On 11.11.2013 09:34, Laurent Bigonville wrote:
> > > > Le Mon, 11 Nov 2013 09:26:38 +0100,
> > > > Sven Hartge <sven@svenhartge.de> a écrit :
> > > >
> > > >> On 11.11.2013 09:22, Laurent Bigonville wrote:
> > > >>> Le Mon, 11 Nov 2013 09:13:46 +0100, Sven Hartge
> > > >>> <sven@svenhartge.de> a écrit :
> > > >>
> > > >>>> I see you reverted the fix you made and reassigned the bug to
> > > >>>> eglibc6 with the commend "affected software needs to be
> > > >>>> recompiled".
> > > >>
> > > >>>> I don't know if I like this "solution". What, if I am not able to
> > > >>>> recompile an affected program?
> > > >>
> > > >>> A binNMU for smartmontools has just been schedule.
> > > >>>
> > > >>> The new rebuilt version (6.2+svn3841-1+b1) of smartmontools should
> > > >>> arrive soon on the archive.
> > > >>
> > > >> All fine and dandy, but what if I have a software showing the same
> > > >> problem, where I am not able to recompile, because I don't have any
> > > >> source code for said software? (This is a hypotethical case.)
> > > >
> > > > Calling ldd /usr/sbin/smartctl was also triggering the same
> > > > assertion.
> > > >
> > > > I tired to run ldd on all the executables that are depending against
> > > > libselinux and only the executables from the smartmontools package
> > > > were showing this issue, so the other packages in the
> > > > archive /should/ be safe.
> > >
> > > Everything from the package pools of Debian may be safe, yes.
> > >
> > > But there are other programs from third party vendors, which may show
> > > the same problem, which cannot be rebuild, because they are
> > > proprietary software. What about them?
>
> > The only versions of libselinux that have been compiled against
> > libpthread are 2.1.13(all revisions) and 2.2-2 The version from wheezy
> > and even squeeze were not, so there is no regressions between stable
> > release here.
> >
> > > The way I see it is that libselinux1 and/or libc6 changed in an
> > > binary-incompatible way and should be fixed in a way which does not
> > > require a rebuild of eventually affected software.
> >
> > Well here it's not a simple ABI change, the loader itself is asserting,
> > that's why I've reassigned the bug to eglibc.
>
> It's possible to trigger the assertion in wheezy, so I don't think it's
> a libc regression. It's more likely due to changes in libselinux, libpcre3
> and/or smartmontools.
Some more remarks about this bug. It's possible to reproduce this bug
with smartmontools from wheezy, and the same way with (e)glibc from
wheezy or jessie. Therefore the bug doesn't seems to come from there.
To be able to reproduce this bug, smartmontools needs to be build with
the following conditions:
- with binutils >= 2.23.52.20130522-1, but using bfd, not gold
- against libselinux1-dev linked against libpcre3 (which in turn might
be linked or not against libthread)
- against libpcre3 linked against libpthread
At runtime it should not be (indirectly) linked against libpthread.
That's why it works in jessie/sid, as libpcre3 is linked against
libpthread.
When comparing the resulting binaries, one might remark the following
differences (- is working, + is not working):
- 82: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_cancel
-740: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_cancel
+123: 0000000000402f70 0 FUNC WEAK DEFAULT UND pthread_cancel@GLIBC_2.2.5 (7)
+719: 0000000000402f70 0 FUNC WEAK DEFAULT UND pthread_cancel@@GLIBC_2.2
The above difference is not present when linking with gold.
It might to be related to one of the bug in the ld/15149 series [1].
Aurelien
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=15149
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: