Re: drop symbol versioning from libsepol and libsemanage?

From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Petr Lautrbach <plautrba@redhat.com>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: drop symbol versioning from libsepol and libsemanage?
Date: Thu, 13 Aug 2020 13:56:57 -0400	[thread overview]
Message-ID: <CAEjxPJ6_V9Uo7XwY89WKX9NBp4ACd5Sn3m7pDf2n+hYH0QYkMw@mail.gmail.com> (raw)
In-Reply-To: <20200813174722.GA14310@localhost.localdomain>

On Thu, Aug 13, 2020 at 1:47 PM Petr Lautrbach <plautrba@redhat.com> wrote:
>
> On Fri, Aug 07, 2020 at 02:54:18PM -0400, Stephen Smalley wrote:
> > As noted in https://github.com/SELinuxProject/selinux/issues/245,
> > symbol versioning in libsepol causes problems for LTO.  libsepol and
> > libsemanage have a handful of versioned symbols due to incompatible
> > ABI changes made early in the CIL integration.  However, as far as I
> > can tell, these symbols were only used by other components of the
> > selinux userspace, not externally.  Should we stop supporting the old
> > versions going forward and simplify the maps? If so, does this truly
> > require bumping the .so version or can we omit that since there are no
> > external users?  Thoughts?
> >
>
> AFAIK libsemanage is used by some 3rd parties. We've had requests to ship
> libsemanage-devel in RHEL-8 repositories in order customers build their
> applications.
>
>
> From my packager POV I like symbol versioning - it helps to prevent some
> dependency issues in development branches, e.g. when libsemanage is built with
> new libsepol symbol but the new package doesn't require newer libsepol. rpm is
> able to solve that:
>
> $ rpm -q --requires libsemanage
> ...
> libselinux(x86-64) >= 3.1-2
> libselinux.so.1()(64bit)
> libselinux.so.1(LIBSELINUX_1.0)(64bit)
> libsepol.so.1()(64bit)
> libsepol.so.1(LIBSEPOL_1.0)(64bit)
> libsepol.so.1(LIBSEPOL_1.1)(64bit)
> libsepol.so.1(LIBSEPOL_3.0)(64bit)
> ...
>
> $ rpm -q --provides libsemanage
> config(libsemanage) = 3.1-2.fc33
> libsemanage = 3.1-2.fc33
> libsemanage(x86-64) = 3.1-2.fc33
> libsemanage.so.1()(64bit)
> libsemanage.so.1(LIBSEMANAGE_1.0)(64bit)
> libsemanage.so.1(LIBSEMANAGE_1.1)(64bit)
>
>
> LTO seems to cause problems to other projects as well
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XMIQMN5KNAZUPX6O3LN6JJGTCZTP4B7J/
>
> So I'd prefer if we try to do and use symbol versioning correctly, but it's not
> hard requirement from my side.

Ok.  An alternative to dropping it altogether is just to try to fix
the particular problem he is seeing with the duplicated symbols in
LIBSEPOL_1_0 and LIBSEPOL_1_1.  If we can remove the duplicate without
breaking anything, then that might suffice for LTO.  I'm not actually
clear on whether it is correct - there are technically two different
versions of the symbol aliased via symver.  If the seeming duplicate
is required then I guess we just have to wait for LTO support to catch
up with symbol versioning.