Practical mod_perlPractical mod_perlSearch this book

Appendix C. ISPs Providing mod_perl Services

Contents:

Users Sharing a Single Web Server
Users Sharing a Single Machine
Giving Each User a Separate Machine (Colocation)
Giving Each User a Virtual Machine

This appendix proposes a few techniques for deploying mod_perl on ISP machines. Therefore, it's mostly relevant to ISP technical teams and ISP users who need to convince their providers to provide them with mod_perl services.

There are at least four different scenarios for deploying mod_perl-enabled Apache servers that ISPs may consider:

This appendix covers each of those scenarios.

C.1. Users Sharing a Single Web Server

An ISP cannot let users run their code under mod_perl on the main server. There are many reasons for this. Here are just a few to consider:

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.



Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.