* drop symbol versioning from libsepol and libsemanage? @ 2020-08-07 18:54 Stephen Smalley 2020-08-13 17:47 ` Petr Lautrbach 0 siblings, 1 reply; 6+ messages in thread From: Stephen Smalley @ 2020-08-07 18:54 UTC (permalink / raw) To: SElinux list 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: drop symbol versioning from libsepol and libsemanage? 2020-08-07 18:54 drop symbol versioning from libsepol and libsemanage? Stephen Smalley @ 2020-08-13 17:47 ` Petr Lautrbach 2020-08-13 17:56 ` Stephen Smalley 0 siblings, 1 reply; 6+ messages in thread From: Petr Lautrbach @ 2020-08-13 17:47 UTC (permalink / raw) To: SElinux list; +Cc: Stephen Smalley [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: drop symbol versioning from libsepol and libsemanage? 2020-08-13 17:47 ` Petr Lautrbach @ 2020-08-13 17:56 ` Stephen Smalley 2020-08-18 13:40 ` Petr Lautrbach 0 siblings, 1 reply; 6+ messages in thread From: Stephen Smalley @ 2020-08-13 17:56 UTC (permalink / raw) To: Petr Lautrbach; +Cc: SElinux list 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: drop symbol versioning from libsepol and libsemanage? 2020-08-13 17:56 ` Stephen Smalley @ 2020-08-18 13:40 ` Petr Lautrbach 2020-08-24 14:15 ` Stephen Smalley 0 siblings, 1 reply; 6+ messages in thread From: Petr Lautrbach @ 2020-08-18 13:40 UTC (permalink / raw) To: SElinux list; +Cc: Stephen Smalley [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: drop symbol versioning from libsepol and libsemanage? 2020-08-18 13:40 ` Petr Lautrbach @ 2020-08-24 14:15 ` Stephen Smalley 2020-08-26 7:47 ` Petr Lautrbach 0 siblings, 1 reply; 6+ messages in thread From: Stephen Smalley @ 2020-08-24 14:15 UTC (permalink / raw) To: Petr Lautrbach; +Cc: SElinux list 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: drop symbol versioning from libsepol and libsemanage? 2020-08-24 14:15 ` Stephen Smalley @ 2020-08-26 7:47 ` Petr Lautrbach 0 siblings, 0 replies; 6+ messages in thread From: Petr Lautrbach @ 2020-08-26 7:47 UTC (permalink / raw) To: SElinux list; +Cc: Stephen Smalley [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-08-26 7:47 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-07 18:54 drop symbol versioning from libsepol and libsemanage? Stephen Smalley 2020-08-13 17:47 ` Petr Lautrbach 2020-08-13 17:56 ` Stephen Smalley 2020-08-18 13:40 ` Petr Lautrbach 2020-08-24 14:15 ` Stephen Smalley 2020-08-26 7:47 ` Petr Lautrbach
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.