perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject mod_perl 2.0 for ISPs
Date Fri, 04 Jan 2002 13:04:02 GMT
hi all...

  I was wondering if any thought was given to designing mod_perl 2.0
with ISPs in mind.  I know this issue has cropped up on modperl@ but
I've been thinking about it lots lately and have an idea (well, some
ramblings, anyway)...

  there are lots of problems with allowing users to have access to
mod_perl in a multiple-client or mass web hosting situation.  of
course, the advocacy bent is that without this type of access,
mod_perl will never reach the level of PHP (if we want it to, that is
:)

  of course, $r->push_handlers(PerlRestartHandler =>
'SomeModuleThatNowRunsAsRoot') is bad, but we can somewhat protect
against that with the current compile time options.  a more subtle
problem is that here we support mod_frontpage, which requires that
$ENV{DOCUMENT_ROOT} be accurately set.  so, basically, anyone who
wants to hose our system for all users (if we are running mod_perl)
only has to create a script that
  $r->document_root('foo');
and access it a few times and *poof* we have an outage for all users.

  so, this led me to two thoughts.  the first is that we need to
protect any method calls/attributes that have a lifetime greater than
the current request in order to be safe in this type of environment. 

the second thought was trying to determine the type of mechansim we
would use to enforce this.  I had in mind some type of pluggable
architecture that allowed a single compile time option to control 'ISP
safe' and 'ISP unsafe' API methods.  I really don't know how this
would be implemented, but I somehow think it should be something that
_every_ API calls plugs into - that way if we discover that an API
method is potentially dangerous we can just flip a switch within the
method that fixes it for the next release instead of having to spend
lots of time with ifdef statements or whatnot.

I tried to think of how the new interpreter architecture would help
the situation, but I wasn't really convinced that it could - I could
be wrong, though.

at any rate, just some random thoughts...

hope everyone had a nice holiday.

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message