While there, also fix tokens handling explanation (for separate commit).
- Group Reviewers
- rS320989: Language improvements.
rS319138: Document direct execution mode for rtld.
A few English comments -- perhaps @wblock could refine further.
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.
This 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
maybe "a direct execution mode..."
as an argument
Allows use of a non-standard dynamic...
I 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"?
a relative path
the search path
options. The argument following -- is ...
Maybe "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.
Some very small nits on which I would happily defer (well, except for the spelling one). Otherwise LGTM.
Misspelling: should be "explicitly"
I think there shouldn't be a comma here?
I 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.
And __progname too, right?
Well, 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.
__progname is not documented and I do not want to add a reference there. It cannot be killed, unfortunately.
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)"?
Ok, 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?
I 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.
I 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.
|312 ↗||(On Diff #28980)|
s/ as follows//
|342 ↗||(On Diff #28980)|
|345 ↗||(On Diff #28980)|
This is a somewhat confusing sentence. Attempt to rewrite:
In the direct execution mode, .Nm emulates verification of the binary execute permission for the current user. This is done to avoid breaking user expectations in naively restricted execution environments. The verification only uses Unix
|354 ↗||(On Diff #28980)|
ISWYM by "racy", but I'm not sure it's a clear description. "its" is not needed. So maybe:
and is naturally prone to race conditions.
|355 ↗||(On Diff #28980)|
|356 ↗||(On Diff #28980)|
and breakable on their own.