FS#33149 - [ruby] Set PaX flags after installation.

Attached to Project: Arch Linux
Opened by henning mueller (phects) - Friday, 21 December 2012, 11:30 GMT
Last edited by Thomas Dziedzic (tomd123) - Sunday, 30 December 2012, 01:15 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Thomas Dziedzic (tomd123)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No



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() {

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

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:

General information about PaX:

More info on MPROTECT:
This task depends upon

Closed by  Thomas Dziedzic (tomd123)
Sunday, 30 December 2012, 01:15 GMT
Reason for closing:  Won't implement
Additional comments about closing:  op is happy with the current state
Comment by Jelle van der Waa (jelly) - Saturday, 22 December 2012, 20:20 GMT
I don't think this will be packaged, since most of us don't use PaX and pacman will error since there won't be a paxctl binary.
Comment by henning mueller (phects) - Saturday, 22 December 2012, 20:25 GMT
pacman won't error with a solution like the one I proposed. For non-PaX users, this would make no difference.
Comment by Thomas Dziedzic (tomd123) - Tuesday, 25 December 2012, 16:45 GMT
I looked into this a little bit, and I'm still uncertain what to do.

Can you point out the logic where gentoo or any other distro disables this flag for ruby?
I tried but had no luck searching the official packages for fedora and gentoo.

Also, I tried googling the need to turn off the mprotect flag off on ruby and found nothing except the one link you mentioned which was needed for including v8:

Essentially, I'm asking for any sort of references.
Since I don't use the grsecurity kernel I can't test any of this.
Comment by henning mueller (phects) - Saturday, 29 December 2012, 18:39 GMT
I experimented with this issue again and I stumbled upon an interesting situation:

When the ruby binary has a PaX header with MPROTECT on, it does not work. If it has a PT_GNU_STACK, it works despite the fact, that MPROTECT should be turned on by default.

For V8 it still will be neccessary to turn off MPROTECT on the ruby binary but the linux-pax-flags script can take care of that.

So I'm happy with this, the issue could be closed for all I care. Thanks for looking into this!

The gentoo folks do not change PaX flags for ruby but an example for a PKGBUILD with changed PaX flags would be firefox (especially look at line 291):