Description:

On kernels patched with grsecurity (which includes PaX patches), a program can not execute parts of memory as code easily, which were written by the program itself. PaX calls this MPROTECT. Some executables, however, need to do this. For this case, PaX flags are deactivatable through an alternative elf header. Binaries with this header do run seamlessly on systems without grsecurity. In gentoo, for example, the PaX flags are stored in the packages themselves and are set after a package installation on a hardened kernel. For Arch Linux I'm maintaining PaX flags for various binaries in an extra package. Currently the script which sets this flags is written in Shellscript. I did a ruby rewrite but this ends up in the chicken or the egg dilemma. The ruby script to set flags can not be run, because flags have to be set on the ruby binary.

So I wondered, if the .install file of the ruby PKGBUILD could set MPROTECT off for the ruby binary, if the "paxctl" utility for setting PaX flags exists on the system.

The post_install() und post_upgrade() functions for example could look like this:

mprotect_off() {
[ -x "$(which paxctl)" ] && paxctl -cm /usr/bin/ruby
# Or simply: paxctl -cm /usr/bin/ruby 2>/dev/null
}

post_install() {
mprotect_off
print_gem_default_target
}

post_upgrade() {
mprotect_off
if [ "$(vercmp $2 1.9.3_p125-4)" -lt 0 ]; then
print_gem_default_target
fi
}


Additional info:

This problem is not version specific. (In an older version of ruby, setting MPROTECT off was not neccessary unless for example a JavaScript engine (like V8) had to be used.)

General information about grsecurity:
http://en.wikipedia.org/wiki/Grsecurity

General information about PaX:
http://en.wikipedia.org/wiki/PaX

More info on MPROTECT:
http://en.wikipedia.org/wiki/PaX#Restricted_mprotect.28.29