Well, for the record, the hardware (PKCS11) library we were using wraps and
exposes some ancient version of OpenSSL.  And was being linked first, blocking
libcrypto.

Andrew


On Tue, Mar 26, 2013 at 12:17:39PM -0300, Andrew Cooke wrote:
> 
> I admit that this is probably not an OpenSSL-specific issue, but perhaps some
> experienced C dev here has seen this before and would be kind enough to
> explain?  Apologies in advance, but (as I hope I can show) it's very odd...
> 
> 
> So, I have a dynamic engine.  One that works with openssl from the command
> line like this:
> 
>   $ openssl engine dynamic -pre
>   SO_PATH:/usr/lib/openssl/engines/libengine_spyrus.so -pre ID:spyrus -pre 
> LOAD
>   -pre MODULE_PATH:/usr/local/ssi_extra/lib/libssi_spyrus.so
>   (dynamic) Dynamic engine loading support
>   [Success]: SO_PATH:/usr/lib/openssl/engines/libengine_spyrus.so
>   [Success]: ID:spyrus
>   [Success]: LOAD
>   [Success]: MODULE_PATH:/usr/local/ssi_extra/lib/libssi_spyrus.so
>   Loaded: (spyrus) SPYRUS LYNKS Series II USB card
> 
> But when I do the same from within a C program, using ENGINE_ctrl_cmd_string,
> I see:
> 
>   $ /usr/local/ssi/bin/token_cert -f ./skm_spyrus.par -vvvUsing param file
>   ./skm_spyrus.par
>   Using key names testAwaitingCertDSA_PrivateKey, 
> testAwaitingCertDSA_PublicKey
>   can't load dynamic engine params
>   6914:error:260B6091:lib(38):func(182):reason(145):eng_dyn.c:399:
>    WARNING: failed to create certificate request!
> 
> Where that error is from the LOAD command.
> 
> BUT if I specify libcrypto explicitly then it LOADs (the failure below is from
> later in the code because the HW is missing):
> 
>   $ LD_PRELOAD=/usr/lib/libcrypto.so.10 /usr/local/ssi/bin/token_cert -f
>   ./skm_spyrus.par -vvvUsing param file ./skm_spyrus.par
>   Using key names testAwaitingCertDSA_PrivateKey, 
> testAwaitingCertDSA_PublicKey
>   opening SPYRUS device 0 failed. No Spyrus device found
>   can't init dynamic engine
>    WARNING: failed to create certificate request!
> 
> Note that the error above is different and occurs after the engine was loaded.
> 
> YET ldd shows that the library being used is /usr/lib/libcrypto.so.10:
> 
>   $ ldd /usr/local/ssi/bin/token_cert | grep crypto
>   libcrypto.so.10 => /usr/lib/libcrypto.so.10 (0x04890000)
>   libk5crypto.so.3 => /lib/libk5crypto.so.3 (0x001fc000)
> 
> so LD_PRELOAD should make no difference, right?
> 
> A similar problem occurs inside gdb.  Without LD_PRELOAD I am unable to step
> into ENGINE_ctrl_cmd_string - it simply returns success on the first few
> calls, before failing on LOAD.  But if I use LD_PRELOAD then I can step into
> libcrypto source!  WHY?!?!??  In both cases the gdb command "info share" shows
> that the /usr/lib/libcrypto.so.10 is loaded!
> 
> I admit I do have a second openssl installed in /usr/local.  And if I
> explicitly select that with LD_PRELOAD it also works.  And this basic problem
> (although not all the details) was happening before I installed that second
> copy (as part of debugging).  SO th eproblem doe snot seem to be a confusion
> between the two libraries, since either works when explicitly selected.
> 
> There is also a system 0.9.8 openssl install, but the above is the 1.0.0
> version:
> 
>   $ sudo find / -name "libcrypto.so*" -exec ls -l \{} \;
>   lrwxrwxrwx. 1 root root 18 Mar 18 17:42 /usr/lib/libcrypto.so ->  
> libcrypto.so.1.0.0
>   -rwxr-xr-x. 1 root root 1358276 Apr 24  2012 /usr/lib/libcrypto.so.0.9.8e
>   lrwxrwxrwx. 1 root root 24 Mar 19 10:14  
> /usr/lib/debug/usr/lib/libcrypto.so.debug -> libcrypto.so.1.0.0.debug
>   lrwxrwxrwx. 1 root root 24 Mar 19 10:14  
> /usr/lib/debug/usr/lib/libcrypto.so.10.debug -> libcrypto.so.1.0.0.debug
>   -r--r--r--. 1 root root 4329128 Mar  4 19:17  
> /usr/lib/debug/usr/lib/libcrypto.so.1.0.0.debug
>   lrwxrwxrwx. 1 root root 19 Mar 18 17:15 /usr/lib/libcrypto.so.6 ->  
> libcrypto.so.0.9.8e
>   lrwxrwxrwx. 1 root root 18 Mar 18 17:41 /usr/lib/libcrypto.so.10 ->  
> libcrypto.so.1.0.0
>   -rwxr-xr-x. 1 root root 1610028 Mar  4 19:17 /usr/lib/libcrypto.so.1.0.0
>   lrwxrwxrwx. 1 root root 18 Mar 25 15:47 /usr/local/ssl/lib/libcrypto.so ->  
> libcrypto.so.1.0.0
>   lrwxrwxrwx. 1 root root 12 Mar 25 11:49 /usr/local/ssl/lib/libcrypto.so.10 
> ->
>   libcrypto.so
>   -r-xr-xr-x. 1 root root 4802798 Mar 25 15:47  
> /usr/local/ssl/lib/libcrypto.so.1.0.0
>   lrwxrwxrwx. 1 ssi ssi 18 Mar 25 15:46 /home/ssi/openssl-1.0.0k/libcrypto.so 
> ->  libcrypto.so.1.0.0
>   -rwxrwxr-x. 1 ssi ssi 4802798 Mar 25 15:46  
> /home/ssi/openssl-1.0.0k/libcrypto.so.1.0.0
> 
> This is all on CentoOS 6 in a VM (installed as 6.2 but it seems to update to
> 6.3 via a "6" repo).  The debug package for openssl 1.0.0 is also installed.
> The programs in question are built by a large tree of automake scripts (large
> package), which seem to be using dynamic (not static) libraries.
> 
> I hope the above is clear.  Any suggestions as to what might be causing the
> program to fail without LD_PRELOAD would be much appreciated.
> 
> Thanks,
> Andrew
> 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to