Php – Apache 2.4 and SuExec configuration

Using suexec and suphp enforce a different type of privilege separation than the default.

The default is to separate the user's permission from the web server. That is, the user owns the files, and he has to grant the web server permission to view and change them.

The suexec/suphp model is that the webserver (when running scripts) runs under the user's account, so the website has permission to do anything that the user has permission to do. To a certain degree, this removes the separation between the user and the webserver, but in exchange it enforces a DIFFERENT separation: that is, between the website of one user and the website of a different user on the same box.

By default, PHP always runs under Apache's user account, so one website's PHP scripts can access any files that another site's PHP scripts can. Therefore, if one account on the server gets hacked, the infection can spread to the others. SuPHP prevents this.

Neither suexec nor suphp will affect the way apache serves static content. All the old rules still apply. Instead, suexec and suphp change the account under which CGI and PHP (respectively) will run. Suexec makes CGI executable run under the owner's account, while SuPHP makes PHP scripts run under the owner's account.

Suexec and SuPHP aren't necessarily better. They're just different. They won't prevent a website from being hacked (and arguably might make the site easier to hack), but they will prevent a compromise on one site from spreading to all the others. To the site administrator, this isolation is arguably more important, which is why some shared hosting systems make suexec and suphp the default.

One extremely common "gotcha" is that SuPHP checks the ownership and permissions of a script before it runs, and will return a 500 error if the permissions aren't appropriate.

In particular:

• The owner and group of the file must match the website owner (as setting in apache configuration)
• The file must not be world-writable
• The parent directory must not be world-writable

Running PHP under the web server's permissions isn't isn't necessarily better or worse than using SuPHP. It's just different. The first model separates the owner from the web server, while the second model separates the owner (and his PHP code) from all the other users on the machine.

Using suPHP doesn't necessarily increase your overall security, it just redirects it. Instead of trying to prevent break-ins, you're isolating the sites from eachother. The justification is that, particularly in a shared-hosting environment, the former security model just wasn't working out: users constantly blew holes in their security by setting world-write permissions on everything so that the web application would work, and then a security compromise on one account would quickly metastasize to all the others on the server.

So, instead, it's common now to use tools like suPHP in large shared-hosting environments to remove the barrier between the user and his PHP application, and instead erect a barrier between a user and his neighbors.

So, in this case, you don't provide security, you provide separation. Unfortunately, suPHP requires that files be owned by the user you intend to run as, so creating a separate FTP user would be... a mess. You'd constantly have to chown files back and forth between the suPHP user and the FTP user.

Instead, you need to pick a role: either you secure a site, or you secure a server. If you want to secure the site, then you need to separate the webserver from the content owner. That's a somewhat complex relationship to maintain correctly, so it's not recommended for shared hosting environments. If, instead, you want to protect the server from its users, then use suPHP to separate the user (and his code) from the others on the server. In this case the user is responsible for his own security. Good luck, user! Technically it is possible to have a secure PHP application--in theory, at least.