Apache Security - Ivan Ristic [77]
Would it be smarter to keep that Apache process running as ivanr around for later when the next request to run a script as ivanr arrives? It would be, and that is what the two projects I describe in the next section are doing.
Perchild MPM and Metux MPM
The Apache 2 branch was intended to have the advanced running-as-actual-user capabilities from day one. This was the job of the mod_perchild module. The idea was simple: instead of switching the whole of Apache to run as root, have one simple process running as root and give it the job of creating other non-root processes as required. When a request for the user ivanr came in, Apache would look to see if any processes were running as ivanr. If not, a new process would be created. If so, the request would be forwarded to the existing process. It sounds simple but mod_perchild never achieved stability.
There is an ongoing effort to replace mod_perchild with equivalent functionality. It is called Metux MPM (http://www.metux.de/mpm/), and there is some talk about the possibility of Metux MPM going into the official Apache code tree, but at the time of this writing it isn't stable either.
The approach used by Perchild MPM and Metux MPM is the only comprehensive solution for the identity problem. I have no doubt a stable and secure solution will be achieved at some point in the future, at which time this long discussion about user identity problems will become a thing of the past.
Multiple Apache instances
One solution to the web server identity problem is to run multiple instances of the Apache web server, each running under its own user account. It is simple, fast, secure, and easy to implement. It is a solution I would choose in most cases. Naturally, there are some problems you will need to overcome.
It is not suitable for mass hosting, where the number of domains per server is in the hundreds or thousands. Having a thousand independent processes to configure and maintain is much more difficult than just one. Also, since a couple of processes must be permanently running for each hosting account, memory requirements are likely to be prohibitive.
Having accepted that this solution is only feasible for more intimate environments (e.g., running internal web applications securely), you must consider possible increased consumption of IP addresses. To have several Apache web servers all run on port 80 (where they are expected to run), you must give them each a separate IP address. I don't think this is a big deal for a few web applications. After all, if you do want to run the applications securely, you will need to have SSL certificates issued for them, and each separate SSL web site requires a separate IP address anyway.
Even without having the separate IP addresses it is still possible to have the Apache web server run on other ports but tunnel access to them exclusively through a master Apache instance running as a reverse proxy on port 80. There may be some performance impact there but likely not much, especially with steady increases of mod_proxy stability and performance.
Other advantages of running separate Apache instances are discussed in Chapter 9.
Sharing Resources
Continuing on the subject of having httpd execute the scripts for all users, the question of shared server resources arises. If httpd is doing all the work, then there is no way to differentiate one user's script from another's. If that's impossible, we cannot control who is using what and for how long. You have two choices here: one is to leave a single httpd user in place and let all users use the server resources as they please. This will work only until someone starts abusing the system, so success basically depends on your luck.
A better solution is to have users' scripts executed under their own user accounts. If you do this, you will be able to take advantage