Stas Bekman wrote: > > Geoffrey Young wrote: > > > 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)... > > agreed that there is a *big* demand for this. No need to have an > advocacy thread on that :) Let's move onto the deep water. > > > 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 > > :) > > We need to adopt concepts of chroot jail. Have you looked at Opcode > module?
I hadn't until now, but yes, that looks like a similar concept to what I had in mind. > If I remember correctly that's the module/functionality that we > need to integrate, so certain opcodes won't be available for the end > users. That's what we need, right? I think so. except that perhaps instead of opcodes, we only need to limit certain API calls that deal with things like the server record. what I think will be really important is the ability to change the limitations easily, so we (or perhaps the person who compiles mod_perl) has the ability to add or remove API calls with ease. that will help it scale better. > > I think the first thing to lookat is how PHP builds the jail. two different issues, no? one is about normal cgi/registry scripts and the other about accessing areas of the server through the API. but yes, registry scripts would need some sort of protection as well. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
