Chapter 7: How Apache or LiteSpeed integrate with InterWorx Up Part II: Advanced Topics

8 PHP integration

InterWorx comes with 2 methods of PHP integration with the Apache webserver. Litespeed has it’s own system for integrating PHP.

8.1 mod_php with Apache

The default out-of-the-box PHP integration method for Apache is using the mod_php module. This integrates PHP’s interpreter directly into the apache daemon processes such that when a PHP script is requested, Apache is able to execute the PHP code on the fly right there without having to summon PHP in an external process.[F][F]Fun fact: if you lsof -p [PID] an apache process with mod_php, you will see all the PHP extentions opened by the apache process, indicative that the interpreter is literally running inside apache.

8.1.1 Advantages

  • Better speed - Apache is able to execute the PHP code directly inside it’s own process, it does not need to spawn another program which has additional CPU and memory overhead.
  • PHP settings can be modified on a per-site basis within .htaccess files using php_value directives.

8.1.2 Disadvantages

  • Security - All user scripts execute as the apache linux user. PHP web applications are often prone to getting attacked by hackers as they are often the most widely-used applications on the internet. Often times, users will not keep their versions of WordPress or Joomla, or even plugins used inside those applications, up to date. This often will allow attackers, who are made aware of a vector of attack from a version changelog, that old versions of the software can be hacked. If a hacker is able to exploit a script in order to upload their own PHP code to the server, they would have:
    • Ability to see all files on the filesytem that the apache user can see, including all files across all sites hosted on your server
    • Ability to open and read files within directories across the entire filesystem that the apache user can see (e.g. they would be able to see MySQL DB passwords for all applications across all sites since the apache user must be able to open and read files)
    • Ability to execute PHP code as the apache user
  • It is much more difficult to trace the domain responsible for the intrusion as all logs will report the apache user as responsible instead of the linux user attached to the SiteWorx account.
  • Changes to the system-wide php.ini will not take effect until Apache is restarted.

8.1.3 Conclusion

mod_php is fine to use if you have a small number of SiteWorx accounts or you are running 1 or 2 large sites off the InterWorx server and you need performance. For larger high-account servers, it is strongly recommended that the next integration type, suPHP is used instead.

8.2 suPHP with Apache

suPHP attacks the security issue by externalizing the execution of PHP scripts from the webserver process and running the script externally in it’s own process as the linux user of the SiteWorx account. It does this by having Apache call /usr/sbin/suphp when a PHP script is requested, which is able to switch user id’s[G][G]The SUID bit is set and the file is owned by the root user and group. Permissions: 4755 or rwsr-xr-x to the linux user of the SiteWorx account and then execute the PHP script with the PHP interpreter, /usr/bin/php-cgi, which recieves browser data via the Common Gateway Interface (CGI)[H][H]http://en.wikipedia.org/wiki/Common_Gateway_Interface. The output of the interpreter is returned to Apache to be sent as the response to the client.

8.2.1 Advantages

  • Per linux user script execution - PHP scripts are executed as the linux user of the SiteWorx account. As such, a hacker gaining access via an exploitable web application will be limited to reading, writing, and executing what the SiteWorx account’s linux user can read, write and execute. With permissions set correctly, this would prevent a hacker from seeing other site’s content or files.
  • System logs (for example, the mail logs), will report the UID of the SiteWorx Account linux user instead of the apache linux user, making it easier to track down the source of spam, or some sort of other intrusion. In addition, the process list will show php-cgi processes with the linux user of the SiteWorx account, making it easier to pinpoint the source of load issues.
  • Per-SiteWorx account php.ini’s in /home/<linux user>/etc/. If no per-siteworx account ini is found, the default system /etc/php.ini is used instead.
  • Users/Groups below UID/GID 500 are not permitted to execute scripts. I.e. suPHP will not allow scripts owned by root to be executed.
  • If the the linux user that is executing a PHP script is writing to a file or making a new file in a directory owned by another user/group (even if permissions are set that this would be allowed), suPHP will disallow the script from writing to that file or that directory. This can be further limited by configuring suPHP’s settings.
  • Changes made to either the system /etc/php.ini or SiteWorx account’s php.ini will see their changes reflected in the next PHP script execution. No server restart required.

8.2.2 Disadvantages

  • Performance Penalty - Due to the need to spawn 2 processes, first suphp and then php-cgi, there is extra overhead added to every PHP script execution. On most servers, this penalty will not incur enough of a load or delay. High-traffic servers may suffer too much and might need to switch to mod_php. The downside in a shared hosting environment is you lose some security.
  • The initial switch to suPHP might need permissions tweaked on existing php files or their enclosing directories in order to get them running correctly. Additionally some permissions might need to be tweaked in order to secure your siteworx accounts and full segregate them.
  • Users expecting to configure PHP settings via .htaccess files will be unable to do so.

8.2.3 Conclusion

For most hosts, this is recommended. In shared hosting environments, it’s impossible to keep an eye on all the applications running on your server. Despite there being a performance penalty, most servers do not see enough traffic on a regular basis to justify using the less secure mod_php.

8.3 Litespeed PHP Integration

If you are using Litespeed in place of Apache, the Litespeed documentation[I][I]http://www.litespeedtech.com/support/wiki/doku.php does a good job of explaining how to setup integration. Basically, litespeed uses a specially patched version of PHP that is able to run in something of a “daemon mode” in which the PHP process is constantly running, and responds to requests from the Litespeed server through a special API where the server sends PHP needed for processing, and the lsphp daemon returning with computation and the output of the PHP script. According to Litespeed, the performance improvement is significant.

Footnotes

[A]Wikipedia’s article helps explain more: http://en.wikipedia.org/wiki/Domain_name
[B]You can learn more about Virtual Hosts at http://httpd.apache.org/docs/2.2/vhosts/
[C]Server aliases can be read about here: http://httpd.apache.org/docs/2.2/mod/core.html#serveralias
[F]Fun fact: if you lsof -p [PID] an apache process with mod_php, you will see all the PHP extentions opened by the apache process, indicative that the interpreter is literally running inside apache.
[G]The SUID bit is set and the file is owned by the root user and group. Permissions: 4755 or rwsr-xr-x

(C) 2017 by InterWorx LLC