I’ve been playing around with RedHat’s newly released Enterprise Linux 5. This comes with PHP 5.1.6, which I’ve taken off my test box and replaced with a copy of PHP 4 built from source.

After installing PHP 4, the first time I tried to start up Apache, it failed with this error:

Cannot load modules/libphp4.so into server: modules/libphp4.so: cannot restore segment prot after reloc: Permission denied

This is an error message from SELinux (which is enabled by default on RHEL5). The error has been triggered because the PHP runtime code contains text relocations – a situation where the code inside the .so has to be writable in memory.

(The definitive place to look for information about text relocations and the risk they pose to the security of your server is this page from Ulrich Drepper).

The quick workaround is to run this command on your server:

chcon -t textrel_shlib_t modules/libphp4.so

This command tells SELinux to allow text relocations inside the libphp4.so Apache module. (Use the command “chcon -t usr_t modules/lib4php.so” to reverse the effect, if you need to).

There are a couple of serious downsides to this workaround. The first one is that it disables one of the protections that SELinux provides. It makes your server more vulnerable to security exploits targetted at the PHP runtime itself. The second problem is that your server uses more memory per Apache process, because each Apache process ends up with its own copy of PHP.

One fix is to recompile your copy of PHP 4 using the “–with-pic” configure option. This produces a copy of PHP that doesn’t contain text relocations. In theory (I haven’t tested this yet), it should also be able to handle more concurrent connections on a server before the server runs out of RAM. Using Apache’s ab benchmarking app, my results suggest that PHP 4 w/ “–with-pic” is about 0.7% slower – small enough not to matter for many folks.

There’s a second way to avoid text relocations – don’t compile with “–with-pic”, and use the prelink tool instead. This tool, run from the command-line, works out the text relocations once, and then writes the data back to the binaries and libraries. From my testing, this avoids the SELinux error, and performance-wise it’s about 0.1% faster than PHP w/ text relocations, and about 0.8% faster than PHP 4 w/ “–with-pic”. This approach should also bring the benefits of reduced memory usage too that go with the “–with-pic” approach, but I haven’t done any testing to confirm this.

Which approach is the best – PHP 4 w/ “–with-pic”, or using prelink? The downside of using prelink is that this approach is reported to be unsuitable for Linux installs configured to do address space randomisation. You also have to remember to re-run prelink everytime you upgrade or re-install PHP. Using PHP 4 w/ “–with-pic” avoids these issues.

No Comments

  1. Matthew Weier O'Phinney says:
    April 4th, 2007 at 7:23 pm

    Just for curiousity’s sake, what requirements do you have that require PHP 4 instead of PHP 5?

  2. Jeremy Johnstone says:
    April 5th, 2007 at 12:31 am

    The other solution to the problem, which for most is the more obvious one, is to allow PHP4 to rest in peace and upgrade to PHP5. It’s been 3 years since it was released, so one would have hoped you could have resolved any backwards compatibility issues (if they existed at all) by now, but I also don’t know the size and quality of your code base either, so that’s just a guess.

  3. Stu says:
    April 5th, 2007 at 8:32 pm

    Hi both,

    Thanks for the feedback.

    I’m using PHP 4 at work because we haven’t yet finished porting our product to run on PHP 5. It’s quite a big job, as our product makes heavy use of Sablotron (missing in PHP 5; there are XSL compatibility issues with moving to libxslt), DOMXML extension (missing in PHP 5; changing all the code to use the DOM extension takes time), Java extension (missing in PHP 5; solution is to re-engineer the Java aspects as web services), and is entirely object oriented (expects objects passed in to methods to be copies, not originals as in PHP 5).

    The issues aren’t just the size of the code base (a few hundred thousand lines of code), but also the maintenance issues for our existing install base. We can’t move all of our customers over to a major upgrade at the drop of a hat, with each upgrade taking man-months of effort not just for ourselves but also for our customers.

    Best regards,

  4. Stu On PHP - » Tucked Away In RedHat Enterprise Server 5’s targeted SELinux Policy … says:
    April 25th, 2007 at 10:38 am

    […] Does this mean that RedHat is shipping a mod_php5 that isn’t compiled for relocatable code support? (See my earlier post on compiling PHP as relocatable code). If they are, according to this page by Ulrich Drepper (hey, doesn’t he work for RedHat? ) then RedHat Enterprise Server 5’s copy of mod_php5 might be using more RAM per Apache process than necessary, which will impact scalability and capacity. […]

  5. sapphirecat says:
    April 27th, 2007 at 11:12 pm

    Hey, thanks for this. We build a “kitchen sink” install of PHP5, yielding a 6MB libphp5.so file. If that’s not shared among (preforked) Apache workers, that adds up quick. That’s before we even get useful data loaded, like the script to run. So I think you just saved us a lot of RAM 🙂

  6. More about Performance Tuning | Stuart Herbert On PHP says:
    January 31st, 2008 at 10:16 pm

    […] up for the cost of how the Linux kernel has to load it into Apache. I touched on the issues with how things are compiled last year, but haven’t followed it up yet with any definitive figures on […]

  7. siva says:
    April 4th, 2011 at 6:51 am

    Dear guys.,

    im having issue with install php 4 on redhat5 system.plz guide me .

  8. i have a paoblem in installing qt? says:
    April 5th, 2011 at 10:19 am

    […] Originally Posted by sandhyasiva HI., i have a problem with php4 istallation with redhat5 system .can anyone guide me its pssible to do or give me a link where i can able to download all php4 rpms. you might want to look at this article for installing php 4 on rh5 : here […]

This Month

April 2007
« Mar   Jul »