Appendix C. ISPs Providing mod_perl Services

C.1. Users Sharing a Single Web Server

Memory usage

One user may deprive other users of memory. A careless user's code might leak memory due to sloppy programming. A user may use a lot of memory simply by loading a lot of modules. If one user's service is very popular and gets a lot of traffic, there will be more Apache children running for that service, so it's possible for that user to unintentionally consume most of the available memory even if she has a very small, well-written code base with no memory leaks.

Other resources

It's not only memory that is shared between all users. Other important resources, such as CPU, the number of open files, the total number of processes (currently there is no easy way to control the number of mod_perl processes dedicated to each user), and process priority are all shared as well. Intentionally or not, users may interfere with each other by consuming any or all of these resources.

File security

All users run code on the server with the same permissions (i.e., the same UID and GID). Any user who can write code for execution by the web server can read any files that are readable by the web server, no matter which user owns them. Similarly, any user who can write code for the web server can write any files that are writable by the web server, no matter which user owns them. Currently, it is not possible to run the suEXEC and cgiwrap extensions under mod_perl, and as mod_perl processes don't normally quit after servicing a request they cannot modify their UIDs and GIDs from request to request.

Potential system compromise via user's code running on the web server

One of the possible solutions here is to use the chroot(1) or jail(8) mechanisms, which allow you to run subsystems isolated from the main system. So if a subsystem gets compromised, the whole system is still safe.

Security of database connections

It's possible to hijack other users' DBI connections, and since all users can read each other's code, database usernames and passwords are visible to every user.

With all the problems described above, it's unwise to let users run their code under mod_perl on a shared server, unless they trust each other and follow strict guidelines to avoid interfering with each other's files and scripts (both of which are unlikely).

Note that there is no reason for an ISP not to run mod_perl applications that they control themselves. The dangers are only when they allow users to write their own mod_perl code. For example, an ISP might provide its users with value-added services such as guest books, hit counters, etc., that run under mod_perl. If the ISP provides code and data, which are not directly accessible by the users, they can still benefit from the performance gains offered by mod_perl.

mod_perl 2.0 improves the situation, since it allows a pool of Perl interpreters to be dedicated to a single virtual host. It is possible to set the UIDs and GIDs of these interpreters to be those of the user for which the virtual host is configured, so users can operate within their own protected spaces and are unable to interfere with other users.