JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Linker and Libraries Guide     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information

Preface

Part I Using the Link-Editor and Runtime Linker

1.  Introduction to the Oracle Solaris Link Editors

2.  Link-Editor

3.  Runtime Linker

4.  Shared Objects

Part II Quick Reference

5.  Link-Editor Quick Reference

Part III Advanced Topics

6.  Direct Bindings

7.  Building Objects to Optimize System Performance

8.  Mapfiles

9.  Interfaces and Versioning

10.  Establishing Dependencies with Dynamic String Tokens

Capability Specific Shared Objects

Reducing Filtee Searches

Instruction Set Specific Shared Objects

Reducing Filtee Searches

System Specific Shared Objects

Locating Associated Dependencies

Dependencies Between Unbundled Products

Security

11.  Extensibility Mechanisms

Part IV ELF Application Binary Interface

12.  Object File Format

13.  Program Loading and Dynamic Linking

14.  Thread-Local Storage

Part V Appendices

A.  Linker and Libraries Updates and New Features

B.  System V Release 4 (Version 1) Mapfiles

Index

Locating Associated Dependencies

Typically, an unbundled product is designed to be installed in a unique location. This product is composed of binaries, shared object dependencies, and associated configuration files. For example, the unbundled product ABC might have the layout shown in the following figure.

Figure 10-1 Unbundled Dependencies

image:Unbundled dependencies example.

Assume that the product is designed for installation under /opt. Normally, you would augment your PATH with /opt/ABC/bin to locate the product's binaries. Each binary locates their dependencies using a hard-coded runpath within the binary. For the application abc, this runpath would be as follows.

$ cc -o abc abc.c -R/opt/ABC/lib -L/opt/ABC/lib -lA
$ elfdump -d abc | egrep 'NEEDED|RUNPATH'
       [0]  NEEDED            0x1b5               libA.so.1
       ....
       [4]  RUNPATH           0x1bf               /opt/ABC/lib

Similarly, for the dependency libA.so.1 the runpath would be as follows.

$ cc -o libA.so.1 -G -Kpic A.c -R/opt/ABC/lib -L/opt/ABC/lib -lB
$ elfdump -d libA.so.1 | egrep 'NEEDED|RUNPATH'
       [0]  NEEDED            0x96                libB.so.1
       [4]  RUNPATH           0xa0                /opt/ABC/lib

This dependency representation works until the product is installed in some directory other than the recommended default.

The dynamic token $ORIGIN expands to the directory in which an object originated. This token is available for filters, runpath, or dependency definitions. Use this technology to redefine the unbundled application to locate its dependencies in terms of $ORIGIN.

$ cc -o abc abc.c '-R$ORIGIN/../lib' -L/opt/ABC/lib -lA
$ elfdump -d abc | egrep 'NEEDED|RUNPATH'
       [0]  NEEDED            0x1b5               libA.so.1
       ....
       [4]  RUNPATH           0x1bf               $ORIGIN/../lib

The dependency libA.so.1 can also be defined in terms of $ORIGIN.

$ cc -o libA.so.1 -G -Kpic A.c '-R$ORIGIN' -L/opt/ABC/lib -lB
$ elfdump -d lib/libA.so.1 | egrep 'NEEDED|RUNPATH'
       [0]  NEEDED            0x96                libB.so.1
       [4]  RUNPATH           0xa0                $ORIGIN

If this product is now installed under /usr/local/ABC and your PATH is augmented with /usr/local/ABC/bin, invocation of the application abc result in a path name lookup for its dependencies as follows.

$ ldd -s abc
....
  find object=libA.so.1; required by abc
    search path=$ORIGIN/../lib  (RUNPATH/RPATH from file abc) 
      trying path=/usr/local/ABC/lib/libA.so.1
        libA.so.1 =>     /usr/local/ABC/lib/libA.so.1
 
  find object=libB.so.1; required by /usr/local/ABC/lib/libA.so.1
    search path=$ORIGIN  (RUNPATH/RPATH from file /usr/local/ABC/lib/libA.so.1)
      trying path=/usr/local/ABC/lib/libB.so.1
        libB.so.1 =>     /usr/local/ABC/lib/libB.so.1

Note - Objects that contain a $ORIGIN token can be referenced using a symbolic link. In this case, the symbolic link is fully resolved in order to determine the true origin of the object.


Dependencies Between Unbundled Products

Another issue related to dependency location is how to establish a model whereby unbundled products express dependencies between themselves.

For example, the unbundled product XYZ might have dependencies on the product ABC. This dependency can be established by a host package installation script. This script generates a symbolic link to the installation point of the ABC product, as shown in the following figure.

Figure 10-2 Unbundled Co-Dependencies

image:Unbundled co-dependencies example.

The binaries and shared objects of the XYZ product can represent their dependencies on the ABC product using the symbolic link. This link is now a stable reference point. For the application xyz, this runpath would be as follows.

$ cc -o xyz xyz.c '-R$ORIGIN/../lib:$ORIGIN/../ABC/lib' \
-L/opt/ABC/lib -lX -lA
$ elfdump -d xyz | egrep 'NEEDED|RUNPATH'
       [0]  NEEDED            0x1b5               libX.so.1
       [1]  NEEDED            0x1bf               libA.so.1
       ....
       [2]  NEEDED            0x18f               libc.so.1
       [5]  RUNPATH           0x1c9               $ORIGIN/../lib:$ORIGIN/../ABC/lib

and similarly for the dependency libX.so.1 this runpath would be as follows.

$ cc -o libX.so.1 -G -Kpic X.c '-R$ORIGIN:$ORIGIN/../ABC/lib' \
-L/opt/ABC/lib -lY -lC
$ elfdump -d libX.so.1 | egrep 'NEEDED|RUNPATH'
       [0]  NEEDED            0x96                libY.so.1
       [1]  NEEDED            0xa0                libC.so.1
       [5]  RUNPATH           0xaa                $ORIGIN:$ORIGIN/../ABC/lib

If this product is now installed under /usr/local/XYZ, its post-install script would be required to establish a symbolic link.

$ ln -s ../ABC /usr/local/XYZ/ABC

If your PATH is augmented with /usr/local/XYZ/bin, then invocation of the application xyz results in a path name lookup for its dependencies as follows.

$ ldd -s xyz
....
  find object=libX.so.1; required by xyz
    search path=$ORIGIN/../lib:$ORIGIN/../ABC/lib  (RUNPATH/RPATH from file xyz)
      trying path=/usr/local/XYZ/lib/libX.so.1
        libX.so.1 =>     /usr/local/XYZ/lib/libX.so.1
 
  find object=libA.so.1; required by xyz
    search path=$ORIGIN/../lib:$ORIGIN/../ABC/lib  (RUNPATH/RPATH from file xyz)
      trying path=/usr/local/XYZ/lib/libA.so.1
      trying path=/usr/local/ABC/lib/libA.so.1
        libA.so.1 =>     /usr/local/ABC/lib/libA.so.1
 
  find object=libY.so.1; required by /usr/local/XYZ/lib/libX.so.1
     search path=$ORIGIN:$ORIGIN/../ABC/lib \
                (RUNPATH/RPATH from file /usr/local/XYZ/lib/libX.so.1)
      trying path=/usr/local/XYZ/lib/libY.so.1
        libY.so.1 =>     /usr/local/XYZ/lib/libY.so.1
 
  find object=libC.so.1; required by /usr/local/XYZ/lib/libX.so.1
     search path=$ORIGIN:$ORIGIN/../ABC/lib \
                (RUNPATH/RPATH from file /usr/local/XYZ/lib/libX.so.1)
      trying path=/usr/local/XYZ/lib/libC.so.1
      trying path=/usr/local/ABC/lib/libC.so.1
        libC.so.1 =>     /usr/local/ABC/lib/libC.so.1
 
  find object=libB.so.1; required by /usr/local/ABC/lib/libA.so.1
     search path=$ORIGIN  (RUNPATH/RPATH from file /usr/local/ABC/lib/libA.so.1)
       trying path=/usr/local/ABC/lib/libB.so.1
        libB.so.1 =>     /usr/local/ABC/lib/libB.so.1

Note - An objects origin can be obtained at runtime using dlinfo(3C) together with the RTLD_DI_ORIGIN flag. This origin path can be used to access additional files from the associated product hierarchy.


Security

In a secure process, the expansion of the $ORIGIN string is allowed only if it expands to a trusted directory. The occurrence of other relative path names, poses a security risk.

A path like $ORIGIN/../lib apparently points to a fixed location, fixed by the location of the executable. However, the location is not actually fixed. A writable directory in the same file system could exploit a secure program that uses $ORIGIN.

The following example shows this possible security breach if $ORIGIN was arbitrarily expanded within a secure process.

$ cd /worldwritable/dir/in/same/fs
$ mkdir bin lib
$ ln $ORIGIN/bin/program bin/program
$ cp ~/crooked-libc.so.1 lib/libc.so.1
$ bin/program
.... using crooked-libc.so.1

You can use the utility crle(1) to specify trusted directories that enable secure applications to use $ORIGIN. Administrators who use this technique should ensure that the target directories are suitably protected from malicious intrusion.