On 2012-06-22 21:22, oh...@cox.net wrote:
Does that confirm that they statically linked stuff from openssl (and
libcrypto) into libobaccess.so?
I think so.
Also you can run nm -aC liboaccess.so. The symbols marked with "U" are
undefined => they are external to the lib. The functions marked with "T"
or "t" are defined by the lib => their code is in the binary.
Functions marked with upper-case ("T") are exported, i.e. another module
may use the function. Functions marked with lower-case ("t") are not
exported. Those functions can be run by other functions in the same
module only. If the libcrypto functions in liboaccess were not exported
(marked with lower-case letter) you wouldn't have a problem: the
functions in liboaccess would execute the libcrypto functions in
liboaccess and the functions in mod_ssl would execute the libcrypto
functions in your system's libcrypto.
But I suppose that's not the case.
Assuming that's the case, is there any way around this?
The easiest way would be to have a liboaccess _dynamically_ linked with
libcrypto. In this case, the first module between mod_ssl and your
module that loads would load libcrypto. When the second module loads,
the loader tries to resolve the undefined symbols of the second module
and it will find them in the already loaded libcrypto.
If you cannot obtain a liboaccess dynamically linked with libcrypto, you
_could_ try to recompile mod_ssl such that it does not export any
libcrypto functions, but I don't know if it is possible.
S
