Dependencies Between Unbundled Products

Another issue related to dependency location is how to establish a model whereby one unbundled product might have dependencies on the shared objects of another unbundled product.

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

Figure C-2 Unbundled Co-Dependencies

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

% dump -Lv xyz
  [1]    NEEDED  libX.so.1
  [2]    NEEDED  libA.so.1
  [3]    RUNPATH $ORIGIN/../lib:$ORIGIN/../ABC/lib

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

% dump -Lv libX.so.1
  [1]    NEEDED  libY.so.1
  [2]    NEEDED  libC.so.1
  [3]    RUNPATH $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 of:

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

If the user's PATH is augmented with /usr/local/XYZ/bin, then invocation of the application xyz will result 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  (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  (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 \
                (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 \
                (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  (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

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.