I think these are good points.
However, to some degree, if this is an attempt to allow an ISP protection,
it's not because most ISPs offer CGI access to their customers.
In addition, the moment you give mod_perl access to a developer they have
the rights to do a LOT of stuff that goes beyond putting PerlHandlers in an
htaccess file.
It's possible to go through the Apache::Registry package and walk the
subroutine tree of precompiled scripts and conceivably figure out stuff
about other people's scripts. Actually probably easier to just figure out
what packages exist in memory and walk the memory and variables directly.
If some of those variables are config vars, then oh well.
In fact, I should think it is conceivable that one mod_perl script could
theoretically replace another mod_perl script within the Apache::Registry
by manipulating the global variables within Apache::Registry.
So in other words, if you can't have a semblance of trust your developers
against each other, then mod_perl simply cannot be configured in a way that
developers can truely share the same web server.
However, I don't think many people advocate sharing mod_perl web servers in
teh real world with apache 1.3. When Apache and mod_perl 2.0 come out, I
suspect the new architecture will allow very cool things like Perl
Interpreter segmentation among virtual hosts. But until that happens,
there's really not much you can do.
It seems to me that mod_perl wasn't really designed for safety against your
own developers doing something malicious. And most if not all people pretty
much run their servers that way. Most people who run mod_perl run it as
their own dedicated server.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
