treat failure of mprotect in map_library as a fatal load failure
authorRich Felker <dalias@aerifal.cx>
Wed, 6 Jun 2012 15:21:28 +0000 (11:21 -0400)
committerRich Felker <dalias@aerifal.cx>
Wed, 6 Jun 2012 15:21:28 +0000 (11:21 -0400)
commitf7d15dcc543c3b65c751064a5e51a0ec462f3cdb
tree1380d48118767c352e1f4604d46519226e2c6bd5
parent908bed20cd877a6c0c290c0c56cc7057ecc00296
treat failure of mprotect in map_library as a fatal load failure

the error will propagate up and be printed to the user at program
start time; at runtime, dlopen will just fail and leave a message for
dlerror.

previously, if mprotect failed, subsequent attempts to perform
relocations would crash the program. this was resulting in an
increasing number of false bug reports on grsec systems where rwx
permission is not possible in cases where users were wrongly
attempting to use non-PIC code in shared libraries. supporting that
usage is in theory possible, but the x86_64 toolchain does not even
support textrels, and the cost of keeping around the necessary
information to handle textrels without rwx permissions is
disproportionate to the benefit (which is essentially just supporting
broken library setups on grsec machines).

also, i unified the error-out code in map_library now that there are 3
places from which munmap might have to be called.
src/ldso/dynlink.c