Re: Detecting dlclose() on an already closed handle?

[Carlos O'Donell <carlos at redhat dot com>]

On 12/22/2016 03:50 PM, Szabolcs Nagy wrote:
> * Carlos O'Donell <carlos@redhat.com> [2016-12-22 11:56:45 -0500]:
>> The only way to reliably test for an error would be, AFAICT, to store the
>> information in the 'void*' whose storage is owned by the caller. You'd have
>> to use an ID and then never recycle the IDs. For 32-bit the ABA happens
>> pretty quickly if you're doing lots of dlopen/dlclose, and we could easily
>> use a larger counter internally to allow the ABA, at the cost of loosing
>> the ability to detect double dlclose() for a dlclose() that happened
>> 4billion dlopen() calls ago.
>>
>> POSIX says:
>> ~~~
>> If the referenced symbol table handle was successfully closed, dlclose() 
>> shall return 0. If handle does not refer to an open symbol table handle 
>> or if the symbol table handle could not be closed, dlclose() shall 
>> return a non-zero value. More detailed diagnostic information shall 
>> be available through dlerror().
>> ~~~
> ...
>> It appears that dlclose() should be able to detect the handle is not
>> open or invalid. We only support that reliably in one scenario:
>> where you recursively call dlclose() and we detect it. All other
> 
> if invalid handle detection is not reliable (because the handle
> may be reused) then i think it can only be a hardening or debug
> measure, but should not be part of the interface contract: it
> must be the responsibility of the caller to use a valid handle.
> (unloading a random module in case of double dlclose is not a
> useful operation.)

That is a very good point, particularly about the reliability
and its relationship to hardening/debug.

> so this seems to be a posix bug.

I agree. The requirement means some state of the dlopen handle
must be kept forever and that has infinite memory requirements.

Bug filed:
http://austingroupbugs.net/view.php?id=1110

-- 
Cheers,
Carlos.