selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Lautrbach <plautrba@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Petr Lautrbach <plautrba@redhat.com>, SELinux <selinux@vger.kernel.org>
Subject: Re: RFC: introduce new library versions for added symbols
Date: Fri, 11 Jan 2019 13:24:53 +0100	[thread overview]
Message-ID: <pjdlg3rfkkq.fsf@redhat.com> (raw)
In-Reply-To: <391a8f7b-b8b0-32a4-29ff-f85eccec0712@tycho.nsa.gov>


Stephen Smalley <sds@tycho.nsa.gov> writes:

> On 1/10/19 12:57 PM, Petr Lautrbach wrote:
>> I used abi-compliance-checker [1] and compared the latest 
>> sources with 2.8
>> release [2].
>> It looks like there's one symbol added to audit2why.so.
>
> audit2why.so needs a .map file or equivalent; it shouldn't be 
> exporting all of
> the libsepol.a symbols.  We don't guarantee ABI or API 
> compatibility for
> anything not in libsepol.map.
>

I'll prepare a patch for that.

>>
>> Then I tried the same thing with 2.7 [3] and 2.6 [4] and 
>> noticed that
>> there were added new symbols even to LIBSEMANAGE_1.0 while 
>> since 2.3
>> there's already LIBSEMANAGE_1.1.
>> It's a bug which breaks automatic dependency checking. So I 
>> propose
>> to fix symbol version mappings in order to be in relation with 
>> the
>> release where they was introduced, e.g. for libsemanage:
>>
>> diff --git a/libsemanage/src/libsemanage.map 
>> b/libsemanage/src/libsemanage.map
>> index 02036696..45e90215 100644
>> --- a/libsemanage/src/libsemanage.map
>> +++ b/libsemanage/src/libsemanage.map
>> @@ -18,8 +18,6 @@ LIBSEMANAGE_1.0 {
>>   semanage_root;
>>   semanage_user_*; semanage_bool_*; semanage_seuser_*;
>>   semanage_iface_*; semanage_port_*; semanage_context_*;
>> - semanage_ibpkey_*;
>> - semanage_ibendport_*;
>>   semanage_node_*;
>>   semanage_fcontext_*; semanage_access_check;
>> semanage_set_create_store;
>>   semanage_is_connected; semanage_get_disable_dontaudit;  
>> semanage_set_disable_dontaudit;
>> @@ -63,3 +61,19 @@ LIBSEMANAGE_1.1 {
>>   semanage_module_remove_key;
>>   semanage_set_store_root;
>> } LIBSEMANAGE_1.0;
>> +
>> +LIBSEMANAGE_2.5 {
>> + global:
>> + semanage_module_extract;
>> +} LIBSEMANAGE_1.1;
>> +
>> +LIBSEMANAGE_2.7 {
>> + global:
>> + semanage_ibpkey_*;
>> + semanage_ibendport_*;
>> +} LIBSEMANAGE_2.5;
>> +
>> +LIBSEMANAGE_2.8 {
>> + global:
>> + semanage_fcontext_list_homedirs;
>> +} LIBSEMANAGE_2.7;
>>
>>
>> If this is acceptable, I would prepare a patch with symbol 
>> versions
>> starting with 2.5 as LIBSEMANAGE_1.1 was introduced in 2.4.
>
> Will this break compatibility for binaries built against earlier
> versions?

I was under impression that is should be enough to list symbols in
different versions but it looks like a symbol is assigned only to
one/the latest version.

# semodule -B
semodule: relocation error: /lib64/libsemanage.so.1: symbol 
sepol_ibendport_modify version LIBSEPOL_1.0 not defined in file 
libsepol.so.1 with link time reference

I'm still investigating this but given that there's only one 
reported
change between the latest and 2.8 and it  should be covered by 
audit2why
map file, it probably doesn't make sense to do this change 
retroactively now.

Just for the future we need to keep in mind that new symbols needs 
new versions
in .map files.



>
>>
>> [1] http://lvc.github.io/abi-compliance-checker/
>> [2]
>> https://plautrba.fedorapeople.org/selinux/compat_reports/2.8_to_2.9-rc0/compat_report.html 
>>
>> [3]
>> https://plautrba.fedorapeople.org/selinux/compat_reports/2.7_to_2.9-rc0/compat_report.html 
>>
>> [4]
>> https://plautrba.fedorapeople.org/selinux/compat_reports/2.6_to_2.9-rc0/compat_report.html 
>>
>>
>> Petr


  reply	other threads:[~2019-01-11 12:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10 17:57 RFC: introduce new library versions for added symbols Petr Lautrbach
2019-01-10 18:13 ` Stephen Smalley
2019-01-11 12:24   ` Petr Lautrbach [this message]
2019-01-11 16:01     ` Stephen Smalley
2019-01-15 13:36       ` [PATCH] libselinux/audit2why.so: Filter out non-python related symbols Petr Lautrbach
2019-01-15 13:57         ` Stephen Smalley
2019-01-17 14:18         ` Stephen Smalley
2019-01-17 14:33           ` Stephen Smalley
2019-01-21 12:15             ` Petr Lautrbach
2019-01-24 11:09               ` Petr Lautrbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pjdlg3rfkkq.fsf@redhat.com \
    --to=plautrba@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).