- 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.
