"Adam Prime" <[EMAIL PROTECTED]> wrote:
> Maybe it's just me, but it seems that the responses richard has gotten
> haven't really touched on the core of the problem. That mod_perl isn't
> exactly friendly to sysadmin's who want to run apache on a (i'm guessing),
> student accessed server, with user dir's and all that other stuff. I'm
> pretty sure (for no particular reason), that there aren't many people on
> this list that are doing that.
I assumed the question was related to the situation of an ISP (or more specifically
web hosting provider) who wants to offer some mod_perl functionality to users on a
shared server. the environment may be similar to the educational scenario, but the
difference is that a web presence provider that is "first" to offer mod_perl (at
prices competitive with oher shared hosting services) stands to differentiate itself
ffrom it's competition and see a signficant revenue reward for it's efforts, either
from being able to charge extra for the mod_perl add-on service, or simply as a swell
of users flock to signup for new service there.
It's an interesting problem in that context. offering mod_perl in such an environment
"safely" would be a big advantage to my hosting provider for instance (pair.com) who
*does* offer custom CGI, is extremely developer-friendly (supports perl, C, php and
python CGI) but has so many users sharing the same httpd that the mod_perl problems
are many and varied. we can't access .conf files or restart apache so we're limited
to .htaccess configuration.
There are so many active developers already that they run "reaper" processes on each
server to kill runaway scripts, and enforce resource limits on user processes.
If they could enforce these rlimits and automatically kill runaway code in users'
mod_perl processes, and *if* those user scripts could be isolated such that they can't
bring down the parent httpd process, mod_perl would be an awesome feature of the
service!
> ...If you have .htaccess stuff turned on right
> now, you can do all sorts of great things through apache that you wouldn't
> want untrusted accounts on the box being able to do.
right. it seems like raw <perl> in .htaccess files would almost *have* to be disabled.
or would it? bad/uncompilable code in .htaccess would just affect the requests that
invoked it, not the parent process...
as long as the server is running as an unpriveledged nobody-user or SetUID as the
~/user who is owns it, the security concerns should be minimal. if a mod_perl process
can attain root priveledges that would, uh, be a bad thing :-)
Of course, in such a restricted environment, many of mod_perl's advantages would be
nullified; scripts would not stay compiled in memory, and modules would be reloaded
on every request (since editing conf files or startup.pl or restarting apache isn't
possible). But hooking into the auth process alone would add a LOT of flexibility to
the many sites hosted on shared servers there.
plus there are endless support requests on "how to do this or that with mod_rewite
regexps"... (i agree with Randal here... how did that ever catch on? heheh).
rewriting and redirecting with mod_perl is *so* much simpler and more flexible.
> The servers that had apache on them for users when i was at school didn't
> even allow normal cgi, so i have no idea how one would approach doing
> something like this with mod_perl.
right. many (lazy) commercial web hosting providers don't even (to this day) offer
perl CGI either. But most decent ones have realized that even the unwashed masses
need perl scripts to run, and have already successfully addressed ExecCGI security
issues in order to remain competitive.
pair has even recently begun to equip servers with mod_php... but i think mod_perl has
been deemed too powerful for use on shared servers, for now... {sigh}
-dave (secretly hoping that the mod_php scripters here crash the servers with endless
loops and stuff)
