On Sat, 18 Jul 2026 at 07:46, Paul Eggert <[email protected]> wrote: > > For this one, two general issues: > > * This implementation doesn't appear to be thread-safe.
Switched to using the 'once' module > * There are several ways to use dlopen: > > 1. Have an initialization procedure, when the application discovers it > needs selinux, it uses that procedure to resolve all the library > symbols. The application arranges to call the initialization procedure > before it uses any selinux feature. This tends to avoid threading > issues, as the initialization procedure can be invoked in the main > thread early on. > > 2. Each selinux function itself invokes the initialization procedure, so > that the app need not know about initialization. > > 3. Even more lazily: each selinux function arranges for itself to be > available (via dlsym), but not the other functions. > > The patch uses (2), but what if an app developer prefers (1) or (3)? (3) > might be better, for example, for apps that need some but not all > selinux functions, especially if selinux evolves. It doesn't make a lot of sense for each function to do its own dlsym, as the common dlopen object is needed anyway, so might as well set up all symbols immediately. An explicit initialization seems overkill, libselinux has implicit global state anyway, it doesn't operate only on explicit caller-owned objects, so it makes things more complex and annoying to use, for little benefit. > What if the app has libselinux linked in for other reasons, before > 'main' even starts? Would that collide with the draft patch? That is, > does the draft patch insist that Gnulib be the only way to use > libselinux functionality? > > > Some more-particular issues: > > The patch to m4/selinux-selinux-h.m4 causes an Android build to insist > on libandroid-selinux.so rather than merely preferring it; is that intended? Latest versions tries first then falls back > No need to include <stdbool.h>; the bool module arranges for C23-style > bool, which doesn't include that file. Ok > Why depend on stddef-h? For the definition of NULL > Why include <sys/stat.h> and depend on sys_stat-h? For the definition of S_ISREG and friends
