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

On 2026-07-30 12:42, Luca Boccassi wrote:

>> There
>> should be some way for them to use selinux-h without also dragging in
>> the 'once' module. Bruno may be able to help here, as he knows more
>> about multithreading.
> 
> Isn't that a huge footgun to leave lying around otherwise?

It's more the other way. Once you drag in 'once' you pull in other multi-threading code and ideas. It's more of a pain to maintain, because it isn't obvious to developers that everything is actually single-threaded. And there are more ways to go wrong, with a bigger attack surface for the executable.

For many single-threaded programs the trend is more to keep things simple, and avoid 'once'. For example, yesterday I installed a patch to GNU 'grep' to do just that in some obscure configuration scenarios; see <https://bugs.gnu.org/81515>.


> Having to remember to synchronize two layers of global state would be
> a gigantic pain for consumers

My intuition is more the other way: because libselinux already has global state that is a gigantic pain for its users, trying to hide that from users does them a disservice. This is not an issue of saving implementation details: it's an issue of making things clear to users.


>>>> Why depend on stddef-h?
>>>
>>> For the definition of NULL
>>
>> I would think that every stddef.h in a Gnulib porting target already
>> defines NULL well enough for selinux-h. A dependency on stddef-h is
>> needed only if selinux-h would otherwise run afoul of the problems noted
>> in doc/posix-headers/stddef.texi, problems that Gnulib fixes.
>>
>> Admittedly this is a minor point.
> 
> The coreutils build yelled at me without it, so it seems not

What were the symptoms? This suggests a more-serious problem, and if so I'd rather not paper over it.