/lib/ld.so.1 [-e envar] dynamic-object [object args]...
During the link-editing of a dynamic executable, a special .interp section, together with an associated program header, is created. This section contains a path name specifying the program's interpreter. An interpreter path name can be specified when the executable is constructed using the -I option to ld(1), the link-editor. The default name supplied by the link-editor is the name of the runtime linker, ld.so.1.
During the process of executing a dynamic executable, the kernel maps the file, and locates the required interpreter. See exec(2) and mmapobj(2). The kernel maps in, and transfers control to, this interpreter. Sufficient information is passed to the interpreter to allow the interpreter to continue to bind, and then execute the application.
In addition to initializing an application, the runtime linker provides services that allow the application to extend its address space. Additional shared objects can be mapped, and symbols within the shared objects can be bound to.
The runtime linker performs the following functions:
Further details on each of the previous topics can be found in the Linker and Libraries Guide.
The runtime linker uses a prescribed search path for locating the dynamic dependencies of an object. The default search paths are the runpath recorded in the object, followed by a series of defaults. For 32-bit objects, the defaults are /lib followed by /usr/lib. For 64-bit objects, the defaults are /lib/64 followed by /usr/lib/64. These defaults component can be modified using a configuration file that is created with crle(1). The runpath is specified when the dynamic object is constructed using the -R option to ld(1). The environment variable LD_LIBRARY_PATH can be used to indicate directories to be searched before the default directories.
The following option is supported:
LD_AUDIT, LD_AUDIT_32, and LD_AUDIT_64
LD_BIND_LAZY, LD_BIND_LAZY_32, and LD_BIND_LAZY_64
If both LD_BIND_LAZY and LD_BIND_NOW are specified, then LD_BIND_NOW takes precedence.
LD_BIND_NOW, LD_BIND_NOW_32, and LD_BIND_NOW_64
If both LD_BIND_NOW and LD_BIND_LAZY are specified, then LD_BIND_NOW takes precedence.
LD_CAP_FILES, LD_CAP_FILES_32, and LD_CAP_FILES_64
Executables and libraries may be specified either by their SONAME or their full real pathname.
LD_CONFIG, LD_CONFIG_32, and LD_CONFIG_64
LD_DEBUG, LD_DEBUG_32, and LD_DEBUG_64
LD_DEMANGLE, LD_DEMANGLE_32, and LD_DEMANGLE_64
LD_FLAGS, LD_FLAGS_32, and LD_FLAGS_64
LD_HWCAP, LD_HWCAP_32, and LD_HWCAP_64
Capabilities may be specified either by name, or as hexadecimal integers with an optional leading bracketed index number specifying the capabilities family.
LD_HWCAP=01 # Sets CA_SUN_HW_1 to 0x1 LD_HWCAP=20 # Sets CA_SUN_HW_2 to 0x20
LD_LIBRARY_PATH, LD_LIBRARY_PATH_32, and LD_LIBRARY_PATH_64
LD_LOADFLTR, LD_LOADFLTR_32, and LD_LOADFLTR_64
LD_NOAUDIT, LD_NOAUDIT_32, and LD_NOAUDIT_64
LD_NOAUXFLTR, LD_NOAUXFLTR_32, and LD_NOAUXFLTR_64
LD_NOCONFIG, LD_NOCONFIG_32, and LD_NOCONFIG_64
LD_NODIRCONFIG, LD_NODIRCONFIG_32, and LD_NODIRCONFIG_64
LD_NODIRECT, LD_NODIRECT_32, and LD_NODIRECT_64
LD_NOENVCONFIG, LD_NOENVCONFIG_32, and LD_NOENVCONFIG_64
LD_NOLAZYLOAD, LD_NOLAZYLOAD_32, and LD_NOLAZYLOAD_64
LD_NOOBJALTER, LD_NOOBJALTER_32, and LD_NOOBJALTER_64
LD_NOVERSION, LD_NOVERSION_32, and LD_NOVERSION_64
LD_ORIGIN, LD_ORIGIN_32, and LD_ORIGIN_64
LD_PRELOAD, LD_PRELOAD_32, and LD_PRELOAD_64
LD_PROFILE, LD_PROFILE_32, and LD_PROFILE_64
The profiling buffer contains profil(2) and call count information. This information is similar to the gmon.out information generated by programs that have been linked with the -xpg option of cc. Any applications that use the named shared object and run while this environment variable is set, accumulate data in the profile buffer. See also NOTES. The profile buffer information can be examined using gprof(1).
The LD_PROFILE profiling technique is an alternative to other techniques that might be provided by the compilation system. The shared object being profiled does not have to be instrumented in any way, and LD_PROFILE should not be combined with a profile-instrumented application. See the Linker and Libraries Guide for more information on profiling shared objects.
LD_SFCAP, LD_SFCAP_32, and LD_SFCAP_64
Capabilities may be specified either by name, or as hexadecimal integers.
LD_SIGNAL, LD_SIGNAL_32, and LD_SIGNAL_64
Notice that environment variable names beginning with the characters 'LD_' are reserved for possible future enhancements to ld(1) and ld.so.1.
The runtime linker categorizes a process as secure if the issetugid(2) system call returns true for the process.
For 32-bit objects, the default trusted directories that are known to the runtime linker are /lib/secure and /usr/lib/secure. For 64-bit objects, the default trusted directories are /lib/secure/64 and /usr/lib/secure/64. The utility crle(1) can be used to specify additional trusted directories that are applicable for secure applications. Administrators who use this technique should ensure that the target directories are suitably protected from malicious intrusion.
If an LD_LIBRARY_PATH family environment variable is in effect for a secure process, only the trusted directories specified by this variable are used to augment the runtime linker's search rules.
In a secure process, runpath components that are provided by the application or any of its dependencies are used, provided the component is a full path name, that is, the path name starts with a '/'.
In a secure process, the expansion of the $ORIGIN string is allowed only if the string expands to a trusted directory. However, should a $ORIGIN expansion match a directory that has already provided dependencies, then the directory is implicitly secure. This directory can be used to provide additional dependencies.
In a secure process, LD_CONFIG is ignored. However, a configuration file that is recorded in a secure application is used. See the -c option of ld(1). A recorded configuration file must be a full path name, that is, the path name starts with a '/'. A recorded configuration file that employs the $ORIGIN string is restricted to known trusted directories. Developers who record a configuration file within a secure application should ensure that the configuration file directory is suitably protected from malicious intrusion. In the absence of a recorded configuration file, a secure process uses the default configuration file, if a configuration file exists. See crle(1).
In a secure process, LD_SIGNAL is ignored.
Additional objects can be loaded with a secure process using the LD_PRELOAD, or LD_AUDIT environment variables. These objects must be specified as full path names or simple file names. Full path names are restricted to known trusted directories. Simple file names, in which no '/' appears in the name, are located subject to the search path restrictions previously described. Simple file names resolve only to known trusted directories.
In a secure process, any dependencies that consist of simple filenames are processed using the path name restrictions previously described. Dependencies expressed as full path names or relative path names are used as is. Therefore, the developer of a secure process should ensure that the target directory referenced as a full path name or relative path name dependency is suitably protected from malicious intrusion.
When creating a secure process, relative path names should not be used to express dependencies, or to construct dlopen(3C) path names. This restriction should be applied to the application and to all dependencies.
The following use of LD_FLAGS is equivalent to setting the individual environment variables LD_BIND_NOW and LD_LIBRARY_PATH for 32-bit applications:
The following use of LD_FLAGS is equivalent to setting the individual environment variables LD_LIBRARY_PATH and LD_PRELOAD for 64-bit applications:
/lib/secure and /usr/lib/secure
/lib/secure/64 and /usr/lib/secure/64
Linker and Libraries Guide
The user compatibility library /firstname.lastname@example.org provides a mechanism that establishes a value of 0 at location 0. Some applications exist that erroneously assume a null character pointer should be treated the same as a pointer to a null string. A segmentation violation occurs in these applications when a null character pointer is accessed. If this library is added to such an application at runtime using LD_PRELOAD, the library provides an environment that is sympathetic to this errant behavior. However, the user compatibility library is intended neither to enable the generation of such applications, nor to endorse this particular programming practice.
In many cases, the presence of /email@example.com is benign, and it can be pre-loaded into programs that do not require it. However, there are exceptions. Some applications, such as the JVM (Java Virtual Machine), require that a segmentation violation be generated from a null pointer access. Applications such as the JVM should not preload /firstname.lastname@example.org.
|December 28, 2020||OmniOS|