httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: [users@httpd] Self-compiled httpd and OpenSSL: Trying to start httpd without using LD_LIBRARY_PATH
Date Fri, 08 Apr 2016 16:54:21 GMT
Hi Chris,

Am 08.04.2016 um 18:09 schrieb Rainer Canavan:
> On Fri, Apr 8, 2016 at 6:02 PM, Christopher Schultz
> <chris@christopherschultz.net> wrote:
> [...]
>> I'm speaking from a position of ignorance, here, but can a dynamic
>> library modify the main process's search path? If only mod_ssl is
>> compiled with the static-path to OpenSSL but httpd is not (and it's
>> not clear to me that httpd is missing this static-path), surely the
>> loadable module isn't modifying the process's library load-path, is it?
>
> The manpage would indicate that the rnupath is only valid for the library
> for which it has been set:
>
> https://docs.oracle.com/cd/E19683-01/816-0210/6m6nb7md6/index.html
>
> The runtime linker uses a prescribed search path for locating the
> dynamic dependencies of an object. The default search paths are
> therunpath recorded in the object, followed by /usr/lib for 32-bit
> objects or /usr/lib/64 for 64-bit objects. This latter component can
> be modified using a configuration file created with crle(1). The
> runpath is specified when the dynamic object is constructed using the
> -Roption to ld(1). LD_LIBRARY_PATH can be used to indicate directories
> to be searched before the default directories.

Adding to that for Solaris:

- there's the loading of the dependencies
and
- there's symbol resolution in the loaded objects

The loading of the dependencies happens immediately. The name of the 
dependencies are encoded in the shared object as the NEEDED entries.

Example:

      index  tag                value
        [0]  NEEDED            0x1331              libssl.so.1.0.0
        [1]  NEEDED            0x1341              libcrypto.so.1.0.0

These are shared object names, not file names.

Looking at some file libssl.so we can see its shared object name:

      index  tag                value
...
        [7]  SONAME            0x4930              libssl.so.1.0.0

Aha, so that file would satisfy the dependency. The SONAMEs are 
typically chosen to express API compatibility.

Where are the files searched for? That's the question Rainer Canavan 
just answered. First on the RUNPATH set in the shared object for which 
we are looking for the dependencies, then in the LD_LIBRARY_PATH, then 
in the globally defined search path.

Example RUNPATH entry:

      index  tag                value
...
        [6]  RUNPATH           0x101ff             /some/path/lib
        [7]  RPATH             0x101ff             /some/path/lib

The ldd command (and ldd -v) shows us the list of dependencies and where 
they are found, but "elfdump -d" resp. "objdump -p" helps to understand, 
what the modules/libs originally demanded.

Finally there comes symbol resolution, i.e. a function that is called in 
a shared object, but provided by another loaded shared object like the 
OpenSSL library. Such a symbol is searched for in the binary and the 
full tree of loaded shared objects and dependencies of this process. On 
Solaris the default order - which can be changed during build time - is 
always first searching in the main binary and then in the other shared 
objects in the order they were loaded. So e.g. a symbol needed by 
mod_ssl will first be looked up in httpd, then in the libs loaded by 
httpd directly, then in the various web server modules and their 
dependencies until finally found e.g. in libssl. One can build modules 
so that symbols are always first searched in their direct dependencies 
before searching in the rest of the process, but that's not the default.

Regards,

Rainer (the other one)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message