Re: [PATCH 2/3] selinux: load libselinux with dlopen instead of linking

Pádraig Brady <[email protected]> Sat, 18 Jul 2026 13:33:58 +0100
Newsgroups gmane.comp.lib.gnulib.bugs
Message-ID <[email protected]>
On 18/07/2026 12:52, Bruno Haible via Gnulib discussion list wrote:
> Hi Luca,
> 
>> libselinux is built in most distros, but it is seldomly needed at
>> runtime (e.g.: it is not used by default on Debian/Ubuntu). In order to
>> allow building small images from the same packages
> 
> libselinux.so is less than 200 KB large. Is it really worth the effort?
> What is the size of "small images" that you are targeting, in MB?

Well it has a pcre2 transitive dependency.

Also there are selinux fs identification overheads at startup,
especially on systems that don't have that, as it scans /proc/mounts
looking for it.

Then there are overheads in utilities themselves,
that could be auto avoided if libselinux was not available.

I am leaning towards libselinux being dlopened for coreutils at least,
as most tools are functional with default options without it.

>> +      AS_CASE([$host_os],
>> +        [*android*], [LIBSELINUX_SONAME=libandroid-selinux.so],
> 
> The handling of Android here is correct. Yes, libandroid-selinux.so
> does not have a major version suffix (unlike shared libraries created
> through libtool).
> 
>> +        [*], [LIBSELINUX_SONAME=libselinux.so.1])
> 
> The major version number of this library has been 1 at least since 2011.
> But it is always possible that it gets superseded by a libselinux.so.2
> some day. How would we know about it?
> 
> The situation I would like to avoid is that the developers of libselinux
> switch to a new major version, we don't know about it, and as a consequence
> coreutils, findutils, and sed don't operate correctly (in subtle ways)
> for a long time — until maybe a year later somebody reports it.
> 
> I don't think always using the newest version (e.g. through
> `readlink libselinux.so`) would work: A major version bump indicates
> backward compatibility problems; so, a developer *must* look into it.
> 
> The only solution I can think of is a piece of configure script that
>    - looks up libselinux.so,
>    - runs `readlink /path/to/libselinux.so`
>    - extracts the major version from that,
>    - aborts the configuration through AC_MSG_ERROR if it is not 1.
> (The use of AC_MSG_ERROR is OK here, since the user can bypass it by
> not using the --enable-selinux option.)
> 
> Can you add something along these lines to m4/selinux-selinux-h.m4 ?

For reference, handling of soname version was done in coreutils with:

https://github.com/coreutils/coreutils/commit/3bbdb3938
https://github.com/coreutils/coreutils/commit/afc41505e

cheers,
Padraig