Request for comments: RTLD_NOEXEC

[Rich Felker <dalias at aerifal dot cx>]

Hi all,

As a result of a recent discussion, it's come to my attention that an
option to dlopen named RTLD_NOEXEC or similar could be very useful.
The semantics would be that global constructors would not be executed,
and the library may (not shall, just may) be mapped non-executable.
Future dlopen calls referencing the same library without RTLD_NOEXEC
option would ensure that constructors run (and that destructors be
registered to run later) and that the load segments are made
executable as appropriate.

The intended usage cases for this option would be things like:

1. Loading shared libraries that are expected to consist purely of
data but which may come from untrusted sources.

2. Loading shared libraries that may come from untrusted sources in
such a way that the loaded image can be checked against a signature
after loading but before being made executable.

3. Path-searching for a library you don't intend to run any code from,
when you're unsure whether the library's global constructors could be
harmful to the state of your program.

4. Validating (e.g. presence of dependencies, necessary
symbols/versions, etc.) a library you don't intend to run any code
from, when you're unsure whether the library's global constructors
could be harmful to the state of your program.

I think usage cases 1 and 2 would still be a bit beyond the scope of
this option, however, unless the dynamic linker is very careful to
check for out-of-bounds values in the library headers. But the other
cases, where the library is known not to be malicious, but may just be
poorly written or not intended to be loaded into the calling
application, seem perfectly reasonable.

Is a feature like this something that would be worth having? Or just
unnecessary complexity?

Rich