Changeset View
Standalone View
libexec/rtld-elf/rtld.1
Show All 22 Lines | |||||
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, | .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, | ||||
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY | .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY | ||||
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT | .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT | ||||
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF | .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF | ||||
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | ||||
.\" | .\" | ||||
.\" $FreeBSD$ | .\" $FreeBSD$ | ||||
.\" | .\" | ||||
.Dd March 16, 2017 | .Dd May 20, 2017 | ||||
.Dt RTLD 1 | .Dt RTLD 1 | ||||
.Os | .Os | ||||
.Sh NAME | .Sh NAME | ||||
.Nm ld-elf.so.1 , | .Nm ld-elf.so.1 , | ||||
.Nm ld.so , | .Nm ld.so , | ||||
.Nm rtld | .Nm rtld | ||||
.Nd run-time link-editor | .Nd run-time link-editor | ||||
.Sh DESCRIPTION | .Sh DESCRIPTION | ||||
Show All 15 Lines | |||||
all objects loaded. | all objects loaded. | ||||
A mechanism is provided for initialization routines | A mechanism is provided for initialization routines | ||||
to be called on a per-object basis, giving a shared object an opportunity | to be called on a per-object basis, giving a shared object an opportunity | ||||
to perform any extra set-up before execution of the program proper begins. | to perform any extra set-up before execution of the program proper begins. | ||||
This is useful for C++ libraries that contain static constructors. | This is useful for C++ libraries that contain static constructors. | ||||
.Pp | .Pp | ||||
When resolving dependencies for the loaded objects, | When resolving dependencies for the loaded objects, | ||||
.Nm | .Nm | ||||
may be allowed to translate dynamic token strings in rpath and soname | translates dynamic token strings in rpath and soname. | ||||
by setting | If the | ||||
.Fl "z origin" | .Fl "z origin" | ||||
option of the static linker | option of the static linker was set when linking the binary, | ||||
the token expansion is performed at the object load time, see | |||||
emaste: This part seems unclear to me, and in fact I wonder if we should just leave it out, or make a… | |||||
.Xr ld 1 . | .Xr ld 1 . | ||||
The following strings are recognized now: | The following strings are recognized now: | ||||
.Bl -tag -width ".Pa $PLATFORM" | .Bl -tag -width ".Pa $PLATFORM" | ||||
.It Pa $ORIGIN | .It Pa $ORIGIN | ||||
Translated to the full path of the loaded object. | Translated to the full path of the loaded object. | ||||
.It Pa $OSNAME | .It Pa $OSNAME | ||||
Translated to the name of the operating system implementation. | Translated to the name of the operating system implementation. | ||||
.It Pa $OSREL | .It Pa $OSREL | ||||
▲ Show 20 Lines • Show All 202 Lines • ▼ Show 20 Lines | |||||
.It Ev LD_LOADFLTR | .It Ev LD_LOADFLTR | ||||
If set, | If set, | ||||
.Nm | .Nm | ||||
will process the filtee dependencies of the loaded objects immediately, | will process the filtee dependencies of the loaded objects immediately, | ||||
instead of postponing it until required. | instead of postponing it until required. | ||||
Normally, the filtees are opened at the time of the first symbol resolution | Normally, the filtees are opened at the time of the first symbol resolution | ||||
from the filter object. | from the filter object. | ||||
.El | .El | ||||
.Sh DIRECT EXECUTION MODE | |||||
Besides typical implicit use of | |||||
.Nm | |||||
during program execution, when kernel loads the dynamic linker | |||||
as requested by the | |||||
Done Inline Actionsof the executed emaste: of the executed | |||||
.Dv PT_INTERP | |||||
program header of executed binary, | |||||
emasteUnsubmitted Done Inline ActionsThis seems overly long, can we split in two sentences - e.g. .Nm is typically used implicitly, loaded by the kernel as requested... . .Fx also supports emaste: This seems overly long, can we split in two sentences - e.g.
.Nm is typically used implicitly… | |||||
.Fx | |||||
Done Inline Actionsthe user emaste: the user | |||||
Done Inline ActionsMisspelling: should be "explicitly" jonathan: Misspelling: should be "explicitly" | |||||
also supports so called direct execution mode for the dynamic linker. | |||||
emasteUnsubmitted Done Inline Actionsmaybe "a direct execution mode..." emaste: maybe "a direct execution mode..."
| |||||
In this mode, user explicitely executes | |||||
Done Inline ActionsI think there shouldn't be a comma here? jonathan: I think there shouldn't be a comma here? | |||||
.Nm | |||||
and provides the path of the program to be linked and executed, as | |||||
emasteUnsubmitted Done Inline Actionsas an argument emaste: as an argument | |||||
Done Inline ActionsProbably "This mode" emaste: Probably "This mode" | |||||
argument. | |||||
Not Done Inline ActionsI wonder if this sentence "This mode allows [...]" is necessary at all? You can use the dynamic linker in two ways, I don't think we need to justify either of them in the man page. jonathan: I wonder if this sentence "This mode allows [...]" is necessary at all? You can use the dynamic… | |||||
Not Done Inline ActionsWell, formally you are right. But this is a (rare) case when I do some logical implications as a useful hint for user, suggesting some application of the feature that might be interesting but not immediately obvious. kib: Well, formally you are right. But this is a (rare) case when I do some logical implications as… | |||||
Not Done Inline ActionsAh, on further thought maybe "without changing the installed dynamic linker." to make that even more obvious. I think there is some value in highlighting this case. emaste: Ah, on further thought maybe "without changing the installed dynamic linker." to make that even… | |||||
Not Done Inline Actions
Ah, yes, that's a good way to put it. If we're documenting this use case, could we also say something like, "or the execution of dynamically-linked binaries from within Capsicum capability mode (see -f option)"? jonathan: > "without changing the installed dynamic linker"
Ah, yes, that's a good way to put it.
If… | |||||
Not Done Inline ActionsI think yes, it worth note the consumer of -f functionality, but it is still not there ? I mean, add this reference to capsicum after the stuff becomes used. kib: I think yes, it worth note the consumer of -f functionality, but it is still not there ? I… | |||||
The mode allows to use non-standard dynamic linker for a program | |||||
emasteUnsubmitted Done Inline ActionsAllows use of a non-standard dynamic... emaste: Allows use of a non-standard dynamic... | |||||
activation without changing the binary, and also allows to specify | |||||
emasteUnsubmitted Done Inline ActionsPerhaps: the binary. emaste: Perhaps:
the binary.
Execution options may be specified. | |||||
some execution options. | |||||
.Pp | |||||
The syntax of the direct invocation is | |||||
.Bd -ragged -offset indent | |||||
.Pa /libexec/ld-elf.so.1 | |||||
.Op Fl f Ar fd | |||||
.Op Fl p | |||||
.Op Fl - | |||||
.Pa image_path | |||||
.Op Ar image arguments | |||||
.Ed | |||||
.Pp | |||||
The options are as follows: | |||||
.Bl -tag -width indent | |||||
Done Inline ActionsIs it fair to just call it "file descriptor <fd>"? I think usage like "fd 6" is common enough. emaste: Is it fair to just call it "file descriptor <fd>"? I think usage like "fd 6" is common enough. | |||||
.It Fl f Ar fd | |||||
File descriptor with index | |||||
.Ar fd | |||||
must be opened in the process, it references the binary which is | |||||
activated by | |||||
emasteUnsubmitted Done Inline ActionsI think ".Ar fd references the binary to be activated by .Nm ." I don't follow "must be opened in the process". Maybe "It must already be opened in the process when executing .Nm"? emaste: I think ".Ar fd references the binary to be activated by .Nm ."
I don't follow "must be opened… | |||||
.Nm . | |||||
If this option is specified, | |||||
.Ar image_path | |||||
Done Inline Actionsprovide the argv emaste: provide the argv | |||||
is only used to provide | |||||
.Va argv[0] | |||||
Not Done Inline ActionsAnd __progname too, right? jonathan: And `__progname` too, right? | |||||
Not Done Inline Actions__progname is not documented and I do not want to add a reference there. It cannot be killed, unfortunately. kib: __progname is not documented and I do not want to add a reference there. It cannot be killed… | |||||
Not Done Inline ActionsI think this is OK if read as argv[0] implying "the program name." emaste: I think this is OK if read as argv[0] implying "the program name." | |||||
Not Done Inline ActionsOk, I guess that's all meant to be "magic" for people writing main() functions. :) Just for my own understanding: if __progname is handled by crt1.o, why do we also set a variable explicitly in ld-elf.so.1? jonathan: Ok, I guess that's all meant to be "magic" for people writing `main()` functions. :)
Just for… | |||||
Not Done Inline ActionsI do not quite understand your question. First, there is no crt1.o for ld-elf.so.1 itself. so rtld have to maintain the variable to not upset some libc routines linked into ld-elf.so.1. Removing libc usage from rtld is a useful project, but nobody taken it to completion. Second, __progname in the main binary is indeed magic. It is set by crt1.o but also it is set even earlier by rtld. Look for call to set_program_var() in _rtld(). The crt1.o does it for the sake of statically-linked binaries, which are executed without help from rtld. Rtld sets the variable for the sake of init() functions in dynamic libraries which are called before the control is transferred to the main binary entry point. kib: I do not quite understand your question. First, there is no crt1.o for ld-elf.so.1 itself. so… | |||||
value to the program. | |||||
.It Fl p | |||||
If the | |||||
.Pa image_path | |||||
argument specifies relative path, | |||||
emasteUnsubmitted Done Inline Actionsa relative path emaste: a relative path | |||||
.Nm | |||||
uses search path specified in the environment variable | |||||
emasteUnsubmitted Done Inline Actionsthe search path emaste: the search path | |||||
.Dv PATH | |||||
to find the binary to execute. | |||||
.It Fl - | |||||
Ends the | |||||
.Nm | |||||
options, next argument is interpreted as the path of binary to execute. | |||||
emasteUnsubmitted Done Inline Actionsoptions. The argument following -- is ... emaste: options. The argument following -- is ... | |||||
.El | |||||
.Pp | |||||
To not break some naively restricted execution environments, | |||||
emasteUnsubmitted Done Inline ActionsMaybe "to conform to user expectation" or such? The argument below about not being a security feature is sensible, but the reason it's done is also a nod to POLA. emaste: Maybe "to conform to user expectation" or such? The argument below about not being a security… | |||||
in the direct execution mode | |||||
.Nm | |||||
emulates verification of the binary execute permission | |||||
for current user. | |||||
The verification only uses Unix | |||||
.Dv DACs , | |||||
ignores | |||||
.Dv ACLs | |||||
and is racy by its nature. | |||||
The environments which rely on such restrictions are weak | |||||
and breakable on its own. | |||||
.Sh FILES | .Sh FILES | ||||
.Bl -tag -width ".Pa /var/run/ld-elf32.so.hints" -compact | .Bl -tag -width ".Pa /var/run/ld-elf32.so.hints" -compact | ||||
.It Pa /var/run/ld-elf.so.hints | .It Pa /var/run/ld-elf.so.hints | ||||
Hints file. | Hints file. | ||||
.It Pa /var/run/ld-elf32.so.hints | .It Pa /var/run/ld-elf32.so.hints | ||||
Hints file for 32-bit binaries on 64-bit system. | Hints file for 32-bit binaries on 64-bit system. | ||||
.It Pa /etc/libmap.conf | .It Pa /etc/libmap.conf | ||||
The libmap configuration file. | The libmap configuration file. | ||||
Show All 10 Lines |
This part seems unclear to me, and in fact I wonder if we should just leave it out, or make a note about DF_ORIGIN and/or -z origin under $ORIGIN below.