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