Controlling user executions with suEXECWritten by Jacob Nicholson
In this article we'll briefly discuss controlling user executions with Apache's suEXEC feature and how it can increase security on your server. If you happen to have read our previous article on choosing the best PHP handler, it was mentioned multiple times that suEXEC can be used to increase security.
suEXEC can be configured on any CGI module for Apache, with suPHP (mod_suphp) and FastCGI (mod_fcgid) being the most common. It operates by having an Apache module call the suEXEC binary, which then wraps the requested script and executes it under the user that owns the script.
By default without suEXEC, anytime a website request is run through Apache which is the web server software, the user which executes the actual process to fulfil the request is the Apache "nobody" user. This is what you'll typically find in a DSO (mod_php) configured PHP environment. Using the suEXEC feature of Apache allows the process execution to instead be handled by the owner of the file itself.
Typically using suEXEC is highly recommended when you're running any type of application that is going to need to modify or write files to the server. Without suEXEC these newly created files would be left with the owner as "nobody", and this can lead to problems displaying them when accessed through that same application. Ensuring that all script executions and owners are set to the same user with suEXEC can also help in tracking down problematic users, as each execution of a script they have will be directly attributed to that user, instead of a generic "nobody" web server user. This information is also logged in the suEXEC log.
Finally suEXEC can help keep your other users secure on the server from exploit attempts. If one user has uploaded a PHP script for example that is exploitable by the outside world, if you are not using suEXEC then the hacker that exploits that one PHP script could possibly view or modify other user's files on the server as well. With suEXEC enabled, at least the exploit would be limited to the one user that uploaded the exploitable PHP script.