path: root/usr/src/man/man1/ld.so.1.1

'\"
.\" Copyright (c) 2009, Sun Microsystems, Inc. All Rights Reserved
.\" Copyright (c) 2014, Joyent, Inc.  All Rights Reserved
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
.\"  See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with
.\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH LD.SO.1 1 "May 8, 2014"
.SH NAME
ld.so.1 \- runtime linker for dynamic objects
.SH SYNOPSIS
.LP
.nf
\fB/lib/ld.so.1\fR
.fi

.LP
.nf
\fB/lib/ld.so.1\fR [\fB-e\fR \fIenvar\fR] \fIdynamic-object\fR [\fIobject args\fR]...
.fi

.SH DESCRIPTION
.sp
.LP
Dynamic applications consist of one or more dynamic objects. A dynamic
application is typically a dynamic executable and one or more shared object
dependencies. As part of the initialization and execution of a dynamic
application, an \fBinterpreter\fR is called. This interpreter completes the
binding of the application to its shared object dependencies. In Solaris, this
interpreter is referred to as the runtime linker.
.sp
.LP
During the link-editing of a dynamic executable, a special \fB\&.interp\fR
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 \fB-I\fR
option to \fBld\fR(1), the link-editor. The default name supplied by the
link-editor is the name of the runtime linker, \fBld.so.1\fR.
.sp
.LP
During the process of executing a dynamic executable, the kernel maps the file,
and locates the required interpreter. See \fBexec\fR(2) and \fBmmapobj\fR(2).
The kernel maps in, and transfers control to, this interpreter. Sufficient
information is passed to the interpretor to allow the interpreter to continue
to bind, and then execute the application.
.sp
.LP
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.
.sp
.LP
The runtime linker performs the following functions:
.RS +4
.TP
.ie t \(bu
.el o
A configuration file, if in existence, is processed. Configuration files can be
employed to alter default search paths, provide a directory cache, and provide
alternative object dependencies. See \fBcrle\fR(1). By default, for 32-bit
objects, the configuration file \fB/var/ld/ld.config\fR is used. For 64-bit
objects, the default configuration file \fB/var/ld/64/ld.config\fR is used.
Alternative configuration files can be specified with the \fBLD_CONFIG\fR
environment variable. Alternative configuration files can also be encoded
within a dynamic executable by using the \fB-c\fR option of \fBld\fR(1).
.RE
.RS +4
.TP
.ie t \(bu
.el o
The runtime linker analyzes the application's dynamic information section,
\fB\&.dynamic\fR, to determine which shared object dependencies are required.
.RE
.RS +4
.TP
.ie t \(bu
.el o
The runtime linker then locates and maps in these dependencies. The dynamic
information section of each dependency is then analyzed to determine if any
additional dependencies are required.
.RE
.RS +4
.TP
.ie t \(bu
.el o
Once all the shared object dependencies are loaded, the runtime linker performs
any necessary relocations. These relocations bind the shared objects in
preparation for process execution.
.RE
.RS +4
.TP
.ie t \(bu
.el o
Any initialization functions provided by the shared object dependencies and,
possibly, by the dynamic executable are called. The functions are called in the
reverse order of the topologically sorted dependencies. If cyclic dependencies
exist, the initialization functions are called using the sorted order with the
cycle removed. \fBldd\fR(1) can be used to display the initialization order of
shared object dependencies.
.RE
.RS +4
.TP
.ie t \(bu
.el o
Control is passed to the application.
.RE
.RS +4
.TP
.ie t \(bu
.el o
During the application's execution, the runtime linker can be called upon to
perform any delayed function binding.
.RE
.RS +4
.TP
.ie t \(bu
.el o
If any shared objects are deleted from the process, finalization functions are
called. By default, these functions are called in the order of the
topologically sorted dependencies.
.RE
.RS +4
.TP
.ie t \(bu
.el o
The application can also call upon the services of the runtime linker to
acquire additional shared objects by using \fBdlopen\fR(3C). Symbols provided
by these objects, can be bound to using \fBdlsym\fR(3C).
.RE
.sp
.LP
Further details on each of the previous topics can be found in the \fILinker
and Libraries Guide\fR.
.sp
.LP
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 \fB/lib\fR followed by \fB/usr/lib\fR. For 64-bit objects, the defaults are
\fB/lib/64\fR followed by \fB/usr/lib/64\fR. These defaults component can be
modified using a configuration file that is created with \fBcrle\fR(1). The
runpath is specified when the dynamic object is constructed using the \fB-R\fR
option to \fBld\fR(1). The environment variable \fBLD_LIBRARY_PATH\fR can be
used to indicate directories to be searched before the default directories.
.SS "Command Line Usage"
.sp
.LP
Typically, the runtime linker is invoked indirectly through executing a dynamic
executable that declares the runtime linker as its interpreter. The runtime
linker can also be executed directly from the command line. This mechanism is
most often employed to experiment with new implementations of the runtime
linker. Arguments that are supplied on the command line consist of options that
are applicable to the runtime linker. Following these options is the name of
the dynamic object to be executed, and any options required by this object.
Effectively, the runtime linker replaces any interpreter specified by the
dynamic object.
.sp
.LP
The following option is supported:
.sp
.ne 2
.na
\fB\fB-e\fR\ envar\fR
.ad
.RS 13n
Specify a runtime linker specific environment variable. See ENVIRONMENT
VARIABLES.
.RE

.SH ENVIRONMENT VARIABLES
.sp
.LP
Each environment variable can be specified with a \fB_32\fR or \fB_64\fR
suffix. This makes the environment variable specific, respectively, to 32-bit
or 64-bit processes. This environment variable overrides any non-suffixed
version of the environment variable that might be in effect. Environment
variables specified without a value, that have a \fB_32\fR or \fB_64\fR suffix,
effectively cancel any associated generic environment variable setting.
.sp
.ne 2
.na
\fB\fBLD_AUDIT\fR, \fBLD_AUDIT_32\fR, and \fBLD_AUDIT_64\fR\fR
.ad
.sp .6
.RS 4n
A colon-separated list of objects that are loaded by the runtime linker. As
each object is loaded, the object is examined for \fILink-Auditing\fR interface
routines. The routines that are present are called as specified in the
\fILink-Auditing\fR interface described in the \fILinker and Libraries
Guide\fR. Also, see the \fB-p\fR and \fB-P\fR options of \fBld\fR(1).
.RE

.sp
.ne 2
.na
\fB\fBLD_BIND_LAZY\fR, \fBLD_BIND_LAZY_32\fR, and \fBLD_BIND_LAZY_64\fR\fR
.ad
.sp .6
.RS 4n
The runtime linker's default mode of performing lazy binding can be enforced by
setting the environment variable \fBLD_BIND_LAZY\fR to any non-null value. This
setting causes the runtime linker to perform only \fBlazy\fR reference
relocations for all objects that are loaded into the process. Individual
objects can request that \fBlazy\fR reference relocations are performed when
the object is loaded. See the \fB-z\fR \fBnow\fR option of \fBld\fR(1), and
\fBdlopen\fR(3C) with the mode \fBRTLD_NOW\fR. Such requests to perform
\fBlazy\fR reference relocations are suppressed when \fBLD_BIND_LAZY\fR is in
effect.
.sp
If both \fBLD_BIND_LAZY\fR and \fBLD_BIND_NOW\fR are specified, then
\fBLD_BIND_NOW\fR takes precedence.
.RE

.sp
.ne 2
.na
\fB\fBLD_BIND_NOW\fR, \fBLD_BIND_NOW_32\fR, and \fBLD_BIND_NOW_64\fR\fR
.ad
.sp .6
.RS 4n
The runtime linker's default mode of performing lazy binding can be overridden
by setting the environment variable \fBLD_BIND_NOW\fR to any non-null value.
This setting causes the runtime linker to perform both \fBimmediate\fR
reference and \fBlazy\fR reference relocations for all objects that are loaded
into the process. Individual objects can request that \fBlazy\fR reference
relocations are performed when the object is loaded. See the \fB-z\fR \fBnow\fR
option of \fBld\fR(1), and \fBdlopen\fR(3C) with the mode \fBRTLD_NOW\fR.
.sp
If both \fBLD_BIND_NOW\fR and \fBLD_BIND_LAZY\fR are specified, then
\fBLD_BIND_NOW\fR takes precedence.
.RE

.sp
.ne 2
.na
\fBLD_CAP_FILES\fR, \fBLD_CAP_FILES_32\fR, and \fBLD_CAP_FILES_64\fR
.ad
.sp .6
.RS 4n
A comma-separated list of executables and shared libraries to which the
alternative capabilities specified by \fBLD_MACHCAP\fR, \fBLD_PLATCAP\fR,
\fBLD_HWCAP\fR and \fBLD_SFCAP\fR should apply.
.LP
Executables and libraries may be specified either by their SONAME or their
full real pathname.
.RE

.sp
.ne 2
.na
\fB\fBLD_CONFIG\fR, \fBLD_CONFIG_32\fR, and \fBLD_CONFIG_64\fR\fR
.ad
.sp .6
.RS 4n
Provides an alternative configuration file. Configuration files can be employed
to alter default search paths, provide a directory cache, and provide alternate
object dependencies. See \fBcrle\fR(1).
.RE

.sp
.ne 2
.na
\fB\fBLD_DEBUG\fR, \fBLD_DEBUG_32\fR, and \fBLD_DEBUG_64\fR\fR
.ad
.sp .6
.RS 4n
Provides a comma, or colon-separated list of tokens to cause the runtime linker
to print debugging information to standard error. The special token \fBhelp\fR
indicates the full list of tokens available. The environment variable
\fBLD_DEBUG_OUTPUT\fR can also be supplied to specify a file to which the
debugging information is sent. The filename is suffixed with the process
\fBID\fR of the application generating the debugging information. See
\fBlari\fR(1).
.RE

.sp
.ne 2
.na
\fB\fBLD_DEMANGLE\fR, \fBLD_DEMANGLE_32\fR, and \fBLD_DEMANGLE_64\fR\fR
.ad
.sp .6
.RS 4n
Any symbol name used as part of a diagnostic message is shown as defined within
an \fBELF\fR file. When \fBLD_DEMANGLE\fR is set to any non-null value, the
runtime linker attempts to decode (demangle) any C++ symbol name.
.RE

.sp
.ne 2
.na
\fB\fBLD_FLAGS\fR, \fBLD_FLAGS_32\fR, and \fBLD_FLAGS_64\fR\fR
.ad
.sp .6
.RS 4n
Provides an alternative means of supplying environment variable information.
Any of the \fBLD_\fR\fIXXX\fR environment variables can be specified as a
\fIxxx\fR token. Multiple tokens can be supplied separated by commas. See
EXAMPLES.
.RE

.sp
.ne 2
.na
\fBLD_HWCAP\fR, \fBLD_HWCAP_32\fR, and \fBLD_HWCAP_64\fR
.ad
.sp .6
.RS 4n
Specify a comma-separated set of alternative hardware capabilities.  A
leading '+' indicates that the capabilities should be included in addition to
the default set, a leading '-' indicates that the capabilities should be
excluded from the default set, and neither indicates that the set should
replace the default set.
.LP
Capabilities may be specified either by name, or as hexadecimal integers with
an optional leading bracketed index number specifying the capabilities family.
.nf
LD_HWCAP=[1]01 # Sets CA_SUN_HW_1 to 0x1
LD_HWCAP=[2]20 # Sets CA_SUN_HW_2 to 0x20
.fi
.RE

.sp
.ne 2
.na
\fBLD_MACHCAP\fR
.ad
.sp .6
.RS 4n
Specify an alternative machine hardware capability name.
.RE

.sp
.ne 2
.na
\fB\fBLD_LIBRARY_PATH\fR, \fBLD_LIBRARY_PATH_32\fR, and
\fBLD_LIBRARY_PATH_64\fR\fR
.ad
.sp .6
.RS 4n
The \fBLD_LIBRARY_PATH\fR environment variable, if set, is used to enhance the
search path that the runtime linker uses to find dynamic dependencies.
\fBLD_LIBRARY_PATH\fR specifies a colon-separated list of directories that are
searched before the default directories. Also notice that \fBLD_LIBRARY_PATH\fR
adds additional semantics to \fBld\fR(1).
.RE

.sp
.ne 2
.na
\fB\fBLD_LOADFLTR\fR, \fBLD_LOADFLTR_32\fR, and \fBLD_LOADFLTR_64\fR\fR
.ad
.sp .6
.RS 4n
Filters are a form of shared object. Filters allow an alternative shared object
to be selected at runtime that provide the implementation for any symbols that
are defined within the filter. See the \fB-f\fR and \fB-F\fR options of
\fBld\fR(1). By default, the alternative shared object processing is deferred
until symbol resolution occurs against the filter. When \fBLD_LOADFLTR\fR is
set to any non-null value, any filters are processed immediately when the
filter is loaded. Also, see the \fB-z\fR \fBloadfltr\fR option of \fBld\fR(1).
.RE

.sp
.ne 2
.na
\fB\fBLD_NOAUDIT\fR, \fBLD_NOAUDIT_32\fR, and \fBLD_NOAUDIT_64\fR\fR
.ad
.sp .6
.RS 4n
Local auditing libraries can be defined within applications and shared objects.
See the \fB-p\fR and \fB-P\fR options of \fBld\fR(1). When \fBLD_NOAUDIT\fR is
set to any non-null value, the runtime linker ignores any local auditing
libraries.
.RE

.sp
.ne 2
.na
\fB\fBLD_NOAUXFLTR\fR, \fBLD_NOAUXFLTR_32\fR, and \fBLD_NOAUXFLTR_64\fR\fR
.ad
.sp .6
.RS 4n
Auxiliary filters are a form of shared object. Auxiliary filters allow an
alternative shared object to be selected at runtime which provides the
implementation for any symbols that are defined within the filter. See the
\fB-f\fR option of \fBld\fR(1). When \fBLD_NOAUXFLTR\fR is set to any non-null
value, the runtime linker disables this alternative shared object lookup.
.RE

.sp
.ne 2
.na
\fB\fBLD_NOCONFIG\fR, \fBLD_NOCONFIG_32\fR, and \fBLD_NOCONFIG_64\fR\fR
.ad
.sp .6
.RS 4n
By default the runtime linker attempts to open and process a configuration
file. When \fBLD_NOCONFIG\fR is set to any non-null value, the runtime linker
disables this configuration file processing.
.RE

.sp
.ne 2
.na
\fB\fBLD_NODIRCONFIG\fR, \fBLD_NODIRCONFIG_32\fR, and
\fBLD_NODIRCONFIG_64\fR\fR
.ad
.sp .6
.RS 4n
Provides a subset of \fBLD_NOCONFIG\fR in that any directory cache information
provided in a configuration file is ignored.
.RE

.sp
.ne 2
.na
\fB\fBLD_NODIRECT\fR, \fBLD_NODIRECT_32\fR, and \fBLD_NODIRECT_64\fR\fR
.ad
.sp .6
.RS 4n
Direct binding information instructs the runtime linker to search directly for
a symbol in an associated object. See the \fB-B\fR \fBdirect\fR option of
\fBld\fR(1). Without direct binding, the symbol search performed by the runtime
linker follows the default model. When \fBLD_NODIRECT\fR is set to any non-null
value, the runtime linker ignores any direct binding information.
.RE

.sp
.ne 2
.na
\fB\fBLD_NOENVCONFIG\fR, \fBLD_NOENVCONFIG_32\fR, and
\fBLD_NOENVCONFIG_64\fR\fR
.ad
.sp .6
.RS 4n
Provides a subset of \fBLD_NOCONFIG\fR in that any environment variables
provided in a configuration file are ignored.
.RE

.sp
.ne 2
.na
\fB\fBLD_NOLAZYLOAD\fR, \fBLD_NOLAZYLOAD_32\fR, and \fBLD_NOLAZYLOAD_64\fR\fR
.ad
.sp .6
.RS 4n
Dependencies that are labeled for lazy loading are not loaded into memory until
explicit reference to the dependency has been made. See the \fB-z\fR
\fBlazyload\fR option of \fBld\fR(1). When \fBLD_NOLAZYLOAD\fR is set to any
non-null value, the runtime linker ignores a dependencies lazy loading label
and loads the dependency immediately.
.RE

.sp
.ne 2
.na
\fB\fBLD_NOOBJALTER\fR, \fBLD_NOOBJALTER_32\fR, and \fBLD_NOOBJALTER_64\fR\fR
.ad
.sp .6
.RS 4n
Provides a subset of \fBLD_NOCONFIG\fR in that any alternative object
dependencies provided in a configuration file are ignored.
.RE

.sp
.ne 2
.na
\fB\fBLD_NOVERSION\fR, \fBLD_NOVERSION_32\fR, and \fBLD_NOVERSION_64\fR\fR
.ad
.sp .6
.RS 4n
By default, the runtime linker verifies version dependencies for the primary
executable and all of its dependencies. When \fBLD_NOVERSION\fR is set to any
non-null value, the runtime linker disables this version checking.
.RE

.sp
.ne 2
.na
\fB\fBLD_ORIGIN\fR, \fBLD_ORIGIN_32\fR, and \fBLD_ORIGIN_64\fR\fR
.ad
.sp .6
.RS 4n
The immediate processing of \fB$ORIGIN\fR can be triggered by setting the
environment variable \fBLD_ORIGIN\fR to any non-null value. Before Solaris 9,
this option was useful for applications that invoked \fBchdir\fR(2) prior to
locating dependencies that employed the \fB$ORIGIN\fR string token. The
establishment of the current working directory by the runtime linker is now
default thus making this option redundant.
.RE

.sp
.ne 2
.na
\fBLD_PLATCAP\fR
.ad
.sp .6
.RS 4n
Specify an alternative platform hardware capability name.
.RE

.sp
.ne 2
.na
\fB\fBLD_PRELOAD\fR, \fBLD_PRELOAD_32\fR, and \fBLD_PRELOAD_64\fR\fR
.ad
.sp .6
.RS 4n
Provides a list of shared objects, separated by spaces. These objects are
loaded after the program being executed but before any other shared objects
that the program references. Symbol definitions provided by the preloaded
objects interpose on references made by the shared objects that the program
references. Symbol definitions provided by the preloaded objects do not
interpose on the symbol definitions provided by the program.
.RE

.sp
.ne 2
.na
\fB\fBLD_PROFILE\fR, \fBLD_PROFILE_32\fR, and \fBLD_PROFILE_64\fR\fR
.ad
.sp .6
.RS 4n
Defines a shared object to be profiled by the runtime linker. When profiling is
enabled, a profiling buffer file is created and mapped. The name of the buffer
file is the name of the shared object being profiled with a \fB\&.profile\fR
extension. By default, this buffer is placed under \fB/var/tmp\fR. The
environment variable \fBLD_PROFILE_OUTPUT\fR can also be supplied to indicate
an alternative directory in which to place the profiling buffer.
.sp
The profiling buffer contains \fBprofil\fR(2) and call count information. This
information is similar to the \fIgmon.out\fR information generated by programs
that have been linked with the \fB-xpg\fR option of \fBcc\fR. 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 \fBgprof\fR(1).
.sp
The \fBLD_PROFILE\fR 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 \fBLD_PROFILE\fR
should not be combined with a profile-instrumented application. See the
\fILinker and Libraries Guide\fR for more information on profiling shared
objects.
.RE

.sp
.ne 2
.na
\fBLD_SFCAP\fR, \fBLD_SFCAP_32\fR, and \fBLD_SFCAP_64\fR
.ad
.sp .6
.RS 4n
Specify a comma-separated set of alternative software capabilities.  A
leading '+' indicates that the capabilities should be included in addition to
the default set, a leading '-' indicates that the capabilities should be
excluded from the default set, and neither indicates that the set should
replace the default set.
.LP
Capabilities may be specified either by name, or as hexadecimal integers.
.RE

.sp
.ne 2
.na
\fB\fBLD_SIGNAL\fR, \fBLD_SIGNAL_32\fR, and \fBLD_SIGNAL_64\fR\fR
.ad
.sp .6
.RS 4n
Provides a \fBnumeric\fR signal number that the runtime linker uses to kill the
process in the event of a fatal runtime error. See \fBthr_kill\fR(3C). By
default, \fBSIGKILL\fR is used. For example, providing the alternative signal
number \fB6\fR (\fBSIGABRT\fR), can provide for the creation of a core file to
aid debugging. See also the \fBRTLD_DI_SETSIGNAL\fR request to
\fBdlinfo\fR(3C).
.RE

.sp
.ne 2
.na
.BR LD_TOXIC_PATH,
.BR LD_TOXIC_PATH_32,
.BR LD_TOXIC_PATH_64,
.ad
.sp .6
.RS 4n
The toxic path refers to a set of paths where by, if
.B ld.so.1
were to load a dependency on that path, rather than loading it, it
should kill the process. This is useful when having built libraries that
while matching the native architecture of the system, are not suitable
to be used, for example, libraries that that correspond to an alternate
release of an operating system.
.RE

.sp
.LP
Notice that environment variable names beginning with the
characters '\fBLD_\fR' are reserved for possible future enhancements to \fBld\fR(1) and
\fBld.so.1\fR.
.SH SECURITY
.sp
.LP
Secure processes have some restrictions applied to the evaluation of their
dependencies and runpaths to prevent malicious dependency substitution or
symbol interposition.
.sp
.LP
The runtime linker categorizes a process as secure if the \fBissetugid\fR(2)
system call returns true for the process.
.sp
.LP
For 32-bit objects, the default trusted directories that are known to the
runtime linker are \fB/lib/secure\fR and \fB/usr/lib/secure\fR. For 64-bit
objects, the default trusted directories are \fB/lib/secure/64\fR and
\fB/usr/lib/secure/64\fR. The utility \fBcrle\fR(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.
.sp
.LP
If an \fBLD_LIBRARY_PATH\fR family environment variable is in effect for a
secure process, only the \fBtrusted\fR directories specified by this variable
are used to augment the runtime linker's search rules.
.sp
.LP
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 '\fB/\fR'.
.sp
.LP
In a secure process, the expansion of the \fB$ORIGIN\fR string is allowed only
if the string expands to a \fBtrusted\fR directory. However, should a
\fB$ORIGIN\fR expansion match a directory that has already provided
dependencies, then the directory is implicitly secure. This directory can be
used to provide additional dependencies.
.sp
.LP
In a secure process, \fBLD_CONFIG\fR is ignored. However, a configuration file
that is recorded in a secure application is used. See the \fB-c\fR option of
\fBld\fR(1). A recorded configuration file must be a full path name, that is,
the path name starts with a '\fB/\fR'. A recorded configuration file that
employs the \fB$ORIGIN\fR 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 \fBcrle\fR(1).
.sp
.LP
In a secure process, \fBLD_SIGNAL\fR is ignored.
.sp
.LP
Additional objects can be loaded with a secure process using the
\fBLD_PRELOAD\fR, or \fBLD_AUDIT\fR environment variables. These objects must
be specified as \fBfull\fR path names or \fBsimple\fR file names. Full path
names are restricted to known \fBtrusted\fR directories. Simple file names, in
which no '\fB/\fR' appears in the name, are located subject to the search path
restrictions previously described. Simple file names resolve only to known
\fBtrusted\fR directories.
.sp
.LP
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.
.sp
.LP
When creating a secure process, relative path names should \fBnot\fR be used to
express dependencies, or to construct \fBdlopen\fR(3C) path names. This
restriction should be applied to the application and to \fBall\fR dependencies.
.SH EXAMPLES
.LP
\fBExample 1 \fRUsing LD_FLAGS to group environment variable information
.sp
.LP
The following use of \fBLD_FLAGS\fR is equivalent to setting the individual
environment variables \fBLD_BIND_NOW\fR and \fBLD_LIBRARY_PATH\fR for 32-bit
applications:

.sp
.in +2
.nf
example% \fBLD_FLAGS_32=bind_now,library_path=/lib/one:/lib/two\fR
.fi
.in -2
.sp

.sp
.LP
The following use of \fBLD_FLAGS\fR is equivalent to setting the individual
environment variables \fBLD_LIBRARY_PATH\fR and \fBLD_PRELOAD\fR for 64-bit
applications:

.sp
.in +2
.nf
example% \fBLD_FLAGS_64=library_path=/lib/one/64,preload=foo.so\fR
.fi
.in -2
.sp

.SH FILES
.sp
.ne 2
.na
\fB\fB/lib/ld.so.1\fR\fR
.ad
.sp .6
.RS 4n
Default runtime linker.
.RE

.sp
.ne 2
.na
\fB\fB/lib/libc.so.1\fR\fR
.ad
.sp .6
.RS 4n
Alternate interpreter for \fBSVID ABI\fR compatibility.
.RE

.sp
.ne 2
.na
\fB\fB/usr/lib/ld.so\fR\fR
.ad
.sp .6
.RS 4n
\fBAOUT\fR (\fBBCP\fR) runtime linker.
.RE

.sp
.ne 2
.na
\fB\fB/usr/lib/0@0.so.1\fR\fR
.ad
.sp .6
.RS 4n
A compatibility library to support null character pointers. See NOTES.
.RE

.sp
.ne 2
.na
\fB\fB/lib/secure\fR and \fB/usr/lib/secure\fR\fR
.ad
.sp .6
.RS 4n
\fBLD_PRELOAD\fR location for secure applications.
.RE

.sp
.ne 2
.na
\fB\fB/lib/secure/64\fR and \fB/usr/lib/secure/64\fR\fR
.ad
.sp .6
.RS 4n
\fBLD_PRELOAD\fR location for secure 64-bit applications.
.RE

.sp
.ne 2
.na
\fB\fB/lib/64/ld.so.1\fR\fR
.ad
.sp .6
.RS 4n
Default runtime linker for 64-bit applications.
.RE

.sp
.ne 2
.na
\fB\fB/usr/lib/64/0@0.so.1\fR\fR
.ad
.sp .6
.RS 4n
A 64-bit compatibility library to support null character pointers. See NOTES.
.RE

.sp
.ne 2
.na
\fB\fB/var/ld/ld.config\fR\fR
.ad
.sp .6
.RS 4n
Default configuration file for 32-bit applications.
.RE

.sp
.ne 2
.na
\fB\fB/var/ld/64/ld.config\fR\fR
.ad
.sp .6
.RS 4n
Default configuration file for 64-bit applications.
.RE

.SH SEE ALSO
.sp
.LP
\fBcrle\fR(1), \fBgprof\fR(1), \fBlari\fR(1), \fBld\fR(1), \fBldd\fR(1),
\fBexec\fR(2), \fBissetugid\fR(2), \fBmmapobj\fR(2), \fBprofil\fR(2),
\fBdladdr\fR(3C), \fBdlclose\fR(3C), \fBdldump\fR(3C), \fBdlerror\fR(3C),
\fBdlinfo\fR(3C), \fBdlopen\fR(3C), \fBdlsym\fR(3C), \fBthr_kill\fR(3C),
\fBproc\fR(4), \fBattributes\fR(5)
.sp
.LP
\fILinker and Libraries Guide\fR
.SH NOTES
.sp
.LP
Care should be exercised when using \fBLD_PROFILE\fR in combination with other
process monitoring techniques, such as users of \fBproc\fR(4). Multiple process
monitoring techniques can result in deadlock conditions that leave the profile
buffer locked. A locked buffer blocks any processes that try to record
profiling information. To reduce this likelihood, the runtime linker's profile
implementation determines if the process is being monitored at startup. If so,
profiling of the process is silently disabled. However, this mechanism can not
catch monitoring processes that attach to the process during its execution.
.sp
.LP
The user compatibility library \fB/usr/lib/0@0.so.1\fR provides a mechanism
that establishes a value of \fB0\fR 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 \fBLD_PRELOAD\fR, 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.
.sp
.LP
In many cases, the presence of \fB/usr/lib/0@0.so.1\fR 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 \fB/usr/lib/0@0.so\fR.