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 C–1 Unbundled Dependencies

Assume that the product is designed for installation under /opt. Normally, you would augment the 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.

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.

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

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 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. This link is now a stable
reference point. For the application xyz, this runpath would be as follows.

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.

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.