Re: Duplicate versions of libsemanage symbols

From: William Roberts <bill.c.roberts@gmail.com>
To: Nicolas Iooss <nicolas.iooss@m4x.org>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: Duplicate versions of libsemanage symbols
Date: Sun, 12 Apr 2020 12:35:07 -0500	[thread overview]
Message-ID: <CAFftDdrh65aF5u__w_6u8sFV+3Prij6AfuQryKGc1=XsFDDmJQ@mail.gmail.com> (raw)
In-Reply-To: <CAFftDdohqX3vdg=VCSEu_1BQhOUv0ry0vRYtchAFecYZOPK-qQ@mail.gmail.com>

On Sun, Apr 12, 2020 at 11:45 AM William Roberts
<bill.c.roberts@gmail.com> wrote:
>
> On Sun, Apr 12, 2020 at 11:27 AM Nicolas Iooss <nicolas.iooss@m4x.org> wrote:
> >
> > Hello,
> > Since recent changes in libsemanage.so's linker script, I have been
> > experiencing issues. As I encountered these issues only when I was
> > using a build configuration which is slightly different from what is
> > in the repository, I wanted to spend time to investigate what was
> > going on before eventually submitting a proper bug report.
> > The issue I see is the following: when I compile with the gold linker
> > and a custom set of build options, linking libsemanage.so fails with
> > [1]:
> >
> > /usr/bin/ld.gold: warning: using 'LIBSEMANAGE_1.0' as version for
> > 'semanage_get_hll_compiler_path' which is also named in version
> > 'LIBSEMANAGE_1.1' in script
> > /usr/bin/ld.gold: warning: using 'LIBSEMANAGE_1.0' as version for
> > 'semanage_get_ignore_module_cache' which is also named in version
> > 'LIBSEMANAGE_1.1' in script
> > /usr/bin/ld.gold: warning: using 'LIBSEMANAGE_1.0' as version for
> > 'semanage_set_ignore_module_cache' which is also named in version
> > 'LIBSEMANAGE_1.1' in script
> > ...
>
> Does it actually fail or just print these warnings? IIRC, @sds replied with some
> superfluous linking warnings, but we ignored them. I tried looking
> through my mail
> and the archive but I couldn't find it.
>
> >
> > Looking back at a normal build of current git master (that succeeded),
> > I indeed have:
> >
> > $ objdump -T libsemanage/src/libsemanage.so | grep
> > semanage_get_hll_compiler_path
> > 000000000001b9b0 g    DF .text 000000000000021c  LIBSEMANAGE_1.0
> > semanage_get_hll_compiler_path
> >
> > The same command on libsemanage 3.0 (last release) gives:
> >
> > $ objdump -T /usr/lib/libsemanage.so | grep semanage_get_hll_compiler_path
> > 000000000001a3c0 g    DF .text 0000000000000224  LIBSEMANAGE_1.1
> > semanage_get_hll_compiler_path
> >
> > In short, semanage_get_hll_compiler_path is defined twice in
> > libsemanage/src/libsemanage.map [2] and the linker only provides the
> > first one. In fact, libsemanage.so built from git master has currently
> > only 2 functions in LIBSEMANAGE_1.1:
> >
> > $ objdump -T libsemanage/src/libsemanage.so | grep LIBSEMANAGE_1.1
> > 000000000001e1f0 g    DF .text 000000000000010d  LIBSEMANAGE_1.1
> > semanage_module_install
> > 000000000001eea0 g    DF .text 000000000000011f  LIBSEMANAGE_1.1
> > semanage_module_get_enabled
> >
> > These functions changed their API between versions 1.0 and 1.1, so
> > this is normal (there are .symver macros in the code and they work
> > properly). The issue is that all the other symbols went into
> > LIBSEMANAGE_1.0 instead of LIBSEMANAGE_1.1. Is this a bug or did I
> > misunderstand something? Should the duplicated functions be removed
> > from LIBSEMANAGE_1.0 in libsemanage.map?
>
> objdump -T is probably a better way to do this than what I had with
> readelf, as it shows the version.
>
> Let me roll a patch, I probably have to go through the others as well.
>
> >
> > Thanks,
> > Nicolas
> >
> > [1] https://travis-ci.org/github/fishilico/selinux/jobs/674002033#L2471
> > [2] https://github.com/SELinuxProject/selinux/blob/aa40067b7b86d5e4c951fccae1aa98baff148613/libsemanage/src/libsemanage.map
> >

FYI the other 2 projects I touched with these changes seem to check out:
 - libselinux checks out ok (it went from base to LIBSELINUX_1.0)
(a41dfeb55d vs current master)
 - libsepol identical (f8c110c8a6 vs current master)