GoFuckYourself.com - Adult Webmaster Forum - View Single Post

raymor · 09-22-2011, 10:54 PM

The following assumes that you have a dedicated server.
On a shared server, there are concerns addressed by running PHP as a CGI using suphp.
Personally I think those concerns are greatly outweighed by what I'm about to explain, but on a shared server it's at least arguable. Assuming this is a dedicated server:

mod_php is the way to go. Do not run PHP as a CGI. There is no benefit to doing so on a dedicated server, only problems.
The error messages you saw were most likely revealing problems previously hidden by a gigantic security whole from running suphp as yourself, your user name.
The error log you posted was the main server log with some probably inconsequential stuff regarding your SSL cert. The log you want to check is the log specific to that site, tailing it as you hit the pages with errors.
You'll see permissions errors.

Here's what was going on, in all likelihood. Running suphp, you basically said permissions (chmod) don't matter. Any visitor to the site was allowed to change or delete any file they want. Since all of the PHP ran as your FTP user, any script, yours or the hackers, was allowed to do anything you can do via FTP. You saw no permission problems because there were effectively no permission controls. "Hey you're visiting this site, I guess you're allowed to change it any way you want." By (correctly) running PHP using the module, permissions are enforced. The scripts can only change the files you say they can change using chmod 666 and can only create new files within the directories you specify by chmodding those data directories 777. Since you didn't set any specific data files or directories, site visitors weren't allowed to change any and you got errors when the scripts couldn't update the data.

The correct error log, the one for the site, should indicate which files and directories the scripts are trying to change. Check those for reasonableness and chmod those files 666 or those directories 777.
By "check for reasonableness" I mean for example scripts, especially customer facing scripts, shouldn't be adding and removing files from your document root. If they are doing that, the script should be corrected to use it's own dedicated data directory.

Suphp and suexec are for when you are more afraid of the other customers hosted on your server than you are of the crackers who will find your site on the web.

09-22-2011, 10:54 PM
raymor Confirmed User Join Date: Oct 2002 Posts: 3,745	The following assumes that you have a dedicated server. On a shared server, there are concerns addressed by running PHP as a CGI using suphp. Personally I think those concerns are greatly outweighed by what I'm about to explain, but on a shared server it's at least arguable. Assuming this is a dedicated server: mod_php is the way to go. Do not run PHP as a CGI. There is no benefit to doing so on a dedicated server, only problems. The error messages you saw were most likely revealing problems previously hidden by a gigantic security whole from running suphp as yourself, your user name. The error log you posted was the main server log with some probably inconsequential stuff regarding your SSL cert. The log you want to check is the log specific to that site, tailing it as you hit the pages with errors. You'll see permissions errors. Here's what was going on, in all likelihood. Running suphp, you basically said permissions (chmod) don't matter. Any visitor to the site was allowed to change or delete any file they want. Since all of the PHP ran as your FTP user, any script, yours or the hackers, was allowed to do anything you can do via FTP. You saw no permission problems because there were effectively no permission controls. "Hey you're visiting this site, I guess you're allowed to change it any way you want." By (correctly) running PHP using the module, permissions are enforced. The scripts can only change the files you say they can change using chmod 666 and can only create new files within the directories you specify by chmodding those data directories 777. Since you didn't set any specific data files or directories, site visitors weren't allowed to change any and you got errors when the scripts couldn't update the data. The correct error log, the one for the site, should indicate which files and directories the scripts are trying to change. Check those for reasonableness and chmod those files 666 or those directories 777. By "check for reasonableness" I mean for example scripts, especially customer facing scripts, shouldn't be adding and removing files from your document root. If they are doing that, the script should be corrected to use it's own dedicated data directory. Suphp and suexec are for when you are more afraid of the other customers hosted on your server than you are of the crackers who will find your site on the web. __________________ For historical display only. This information is not current: support@bettercgi.com ICQ 7208627 Strongbox - The next generation in site security Throttlebox - The next generation in bandwidth control Clonebox - Backup and disaster recovery on steroids