1

I am considering using suphp. It seems that newly created files in php get ownership apache.apache and this can become an issue. Also it seems that monitoring of spam sent and load usage by php scripts is easier to monitor with suphp.

However I am afraid this will reduce performance on the servers. I use the Plesk and DirectAdmin control panel for servers and host about 200 domains per server, but I don't want to see a high increase in load with suphp. Also I am not sure if suphp is just a fancy name for php via cgi.

suphp

  • almost 10 times slower?
  • this is just php under cgi? the way we did it 10 years ago?
  • easier for monitoring, all scripts run under username.
  • minimum permissions = 640.

mod_php

  • much faster
  • better integration with apache?
  • scripts run under apache:apache.
  • minimum permissions = 64 4(!), reading of password files only restricted by open_basedir, not the actual linux default permisisons system?

So... does suphp offer increased security? and does it offer much benefits in monitoring threats (spam), benchmarking (spiking php scripts), etc? And how big is the drain in performance?

ujjain
  • 3,963
  • 15
  • 50
  • 88

2 Answers2

3

suphp is not the same thing as PHP, there are a number of functional differences.

Running a standard CGI interface is much slower than fastCGI / webserver module. AFAIK suphp does not support fastCGI - but there is now an apache module version. It does provide some security tweaks that are not available in the standard PHP, however the latter is not exactly poor in this regard. The most important quetions are whether you are happy to maintain the software from tarballs and whether your users will be happy with a version of PHP which lags behind the official version ni its functionality.

Whichever version you go for, it will only provide as much security as you configure. If you decide on standard PHP, then do make sure that:

1) you set open_basedir to constrain users to their own directories

2) you may want to disable allow_url_fopen

3) you should definitely disable allow-url-include

4) if you want a very restrictive system then disable eval and create_function

5) set a per-user include_path

6) change sendmail_path to point to a wrapper script which logs the account being used (you should be able to work this out from the cwd) and imlpements quotas

7) set the session.save_path to a per user location

I'm not aware of anything in suphp which specifically addresses spamming - but you can easily add your own wrapper script as described above. Note that most of the steps above will apply to suphp to - it just makes it easier to drop in paramters in the config file directives rather than overriding them in the apache config or via .htaccess.

symcbean
  • 19,931
  • 1
  • 29
  • 49
0

I recommend using the ITK MPM instead. You'll have to run a separate VirtualHost for each user, but you might be doing that anyway. However, if you're running mod_userdir, you're out of luck and have to use suphp to get proper separation.

Teddy
  • 5,134
  • 1
  • 22
  • 27