[Opencryptoki-tech] apiutil.c leaks file descriptor with dlopen/close

[Mike G. <ge...@go...>]

Hi Folks,

While using opencryptoki with wpa_supplicant I noticed that it seemed to
leak
file descriptors slowly over time. /proc/${pid}/fd showed me it was opening
a
lot of file descriptors for /var/run/opencryptoki/LCK..APIlock, which I've
tracked down to the fact that xplfd in usr/lib/pkcs11/api/apiutil.c never
actually gets closed, it just gets opened once when the fd is negative
(which
it is statically initialized to). This works fine normally, but when
opencryptoki is opened with dlopen using glibc this causes the file
descriptor
to be leaked as the fd is opened when C_Initialize is called, but never
closed
when C_Finalize is called, and if we happen to dlclose in the meantime the
xplfd is re-initialized to -1 the next time the library is loaded and
another
descriptor is opened for the file.

This can easily be reproduced by just dlopen'ing opencryptoki, Initializing
it,
Finalizing it, dlclosing it, and repeating, noticing that each repetition
leaks
one more file descriptor.

I won't have the time to put together a patch for this since I only noticed
the
issue in passing while working out a problem with another PKCS#11 module,
but
while a simple patch might be to close this fd on C_Finalize I tend to think
that having opencryptoki just call dlopen on itself so it never gets
unloaded
is perfectly reasonable. Because of cases like this and many others
unloading a
library on dlclose is actually pretty prone to breakage, which is why plenty
of other libcs (like musl) explicitly do not unload libraries when they are
dlclose'd. But I'm sure you all know will know what the appropriate fix is.

I saw this issue in opencryptoki 2.4.2 on Linux, but just browsing the
current
version in the git repo appears to indicate the same issue still exists in
master as well.

-- 
Mike Gerow
ge...@go...