drop symbol versioning from libsepol and libsemanage?

drop symbol versioning from libsepol and libsemanage?

[Stephen Smalley]

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?

Re: drop symbol versioning from libsepol and libsemanage?

[Petr Lautrbach]

[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]

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.

Petr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: drop symbol versioning from libsepol and libsemanage?

[Stephen Smalley]

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.

Re: drop symbol versioning from libsepol and libsemanage?

[Petr Lautrbach]

[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]

On Thu, Aug 13, 2020 at 01:56:57PM -0400, Stephen Smalley wrote:
> 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.
> 

In this particular case I'd drop duplicate symbols from libsepol. It's about 4
years and 5 releases since it was added and it would slightly clean the code. It
would be properly announced in release notes. And if there's anybody else then
libsemage who uses it they would need either to rebuild their sources or stay
with the current version.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: drop symbol versioning from libsepol and libsemanage?

[Stephen Smalley]

On Tue, Aug 18, 2020 at 9:40 AM Petr Lautrbach <plautrba@redhat.com> wrote:
>
> On Thu, Aug 13, 2020 at 01:56:57PM -0400, Stephen Smalley wrote:
> > 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.
> >
>
> In this particular case I'd drop duplicate symbols from libsepol. It's about 4
> years and 5 releases since it was added and it would slightly clean the code. It
> would be properly announced in release notes. And if there's anybody else then
> libsemage who uses it they would need either to rebuild their sources or stay
> with the current version.

Not entirely sure what this means.  We can do either of the following options:

1.  Just remove the duplicated symbol names from libsepol.map.in (i.e.
only define them once in either LIBSEPOL_1.0 or LIBSEPOL_1.1 not in
both).  That might solve the problem for LTO without creating any
compatibility issues for non-LTO; I'm not sure.

-or-

2. Get rid of the duplicated symbols in libsepol.map.in AND drop the
old symbol definitions and the old functions from cil/src/cil.c,
renaming the new symbols to the exported name and dropping use of
symver there.  This is an ABI change for libsepol but likely only
affects libsemanage. If we do this, do we bump its .so version to
reflect the incompatible change?

Re: drop symbol versioning from libsepol and libsemanage?

[Petr Lautrbach]

[-- Attachment #1: Type: text/plain, Size: 4437 bytes --]

On Mon, Aug 24, 2020 at 10:15:27AM -0400, Stephen Smalley wrote:
> On Tue, Aug 18, 2020 at 9:40 AM Petr Lautrbach <plautrba@redhat.com> wrote:
> >
> > On Thu, Aug 13, 2020 at 01:56:57PM -0400, Stephen Smalley wrote:
> > > 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.
> > >
> >
> > In this particular case I'd drop duplicate symbols from libsepol. It's about 4
> > years and 5 releases since it was added and it would slightly clean the code. It
> > would be properly announced in release notes. And if there's anybody else then
> > libsemage who uses it they would need either to rebuild their sources or stay
> > with the current version.
> 
> Not entirely sure what this means.  We can do either of the following options:
> 
> 1.  Just remove the duplicated symbol names from libsepol.map.in (i.e.
> only define them once in either LIBSEPOL_1.0 or LIBSEPOL_1.1 not in
> both).  That might solve the problem for LTO without creating any
> compatibility issues for non-LTO; I'm not sure.
> 
> -or-
> 
> 2. Get rid of the duplicated symbols in libsepol.map.in AND drop the
> old symbol definitions and the old functions from cil/src/cil.c,
> renaming the new symbols to the exported name and dropping use of
> symver there.  This is an ABI change for libsepol but likely only
> affects libsemanage. If we do this, do we bump its .so version to
> reflect the incompatible change?
> 

I'd go with 2 - get rid of old symbols, drop duplication from .map file and bump
.so version.

I could prepare a patch with this next week.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]