Request for review [new bug](S): Stack guard pages are no more protected after loading a shared library with executable stack.

[Lindenmaier, Goetz]

Hi Dmitry and Florian, 

> 1. What is the reason to keep an executable stack in the library?
>    It still will not work with SELinux config.
There are old applications not running on SELinux.  If these contain and 
load a jni library without proper stack settings, this issue arises.  They 
will not be able to detect stack overflows.

> 2. It's seems to me that with RTLD_LAZY kernel change a protection of
>    stack guard page not at the time of dl_open call but at the time of
>    actual library loading.
As I understand, RTLD_LAZY affects symbol resolution. I could not find
documentation telling how ldopen treats stack protection. But I observed
in my experiments that the stack protection is lost after dlopen completed.
You can also see this in the /proc/self/maps file, where stack access 
rights change from rw to rwx. 

Florian, I don't think it's an option to change the stack back to 
executable.

> In most case executable stack is not necessary now days. The only case
> in my memory, where executable stack is really necessary - code using
> nested functions, as gcc generate trampolines on the stack.
Yes, that's my understanding, too. The problem is just that there are
libs around where the stack is set wrong.  One can simply fix these
libs with execstack -c <lib>, but this requires that an application
is fixed and updated before the Java user updates a VM or switches 
to Java 7.

Best regards,
  Goetz.