Re: Apache::VirtualHostRegistry
On Fri, 17 Nov 2000, Gunther Birznieks wrote: > At 11:15 AM 11/17/00 +, Matthew Byng-Maddick wrote: > >man jail() on FreeBSD 4. > But then you lose the benefits of having shared apache processes among many > shared users many of whom may have very non-busy web sites. No? Yes, but this is the only way to reliably have security with mod_perl in such a way as they can't interfere with anyone else's code. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) In California they don't throw their garbage away -- they make it into television shows. -- Woody Allen, "Annie Hall" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::VirtualHostRegistry
At 11:15 AM 11/17/00 +, Matthew Byng-Maddick wrote: >On Fri, 17 Nov 2000, Nigel Hamilton wrote: > > Going along ths lines of sharing mod_perl between users for ISPs > > is there a median position that tempers security concerns/support > > costs/hassles etc that a CPAN module could fill? > >I wouldn't do it like that. Regardless of wanting to do it like that, I dont think you can do it like that. Perl code can't truly segment other arbitrarily written Perl code yet. The way to do it is as I said in my last post. You need Apache 2.0/mod_perl 2.0 so that you can explicitly designate perl interpeter pools to be assigned to certain virtual hosts. > > I'm thinking of a module like APache::Registry but it segments the > > namespace/memory netween virtual servers --- a sandbox that each virtual > > host is kept in? > >man jail() on FreeBSD 4. But then you lose the benefits of having shared apache processes among many shared users many of whom may have very non-busy web sites. No? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::VirtualHostRegistry
On Fri, 17 Nov 2000, Nigel Hamilton wrote: > Going along ths lines of sharing mod_perl between users for ISPs > is there a median position that tempers security concerns/support > costs/hassles etc that a CPAN module could fill? I wouldn't do it like that. > I'm thinking of a module like APache::Registry but it segments the > namespace/memory netween virtual servers --- a sandbox that each virtual > host is kept in? man jail() on FreeBSD 4. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) In California they don't throw their garbage away -- they make it into television shows. -- Woody Allen, "Annie Hall" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache::VirtualHostRegistry
Hi, Going along ths lines of sharing mod_perl between users for ISPs is there a median position that tempers security concerns/support costs/hassles etc that a CPAN module could fill? I'm thinking of a module like APache::Registry but it segments the namespace/memory netween virtual servers --- a sandbox that each virtual host is kept in? NIge Nigel Hamilton __ http://e1mail.come1mail - Encrypted 1st Class Maile1mail: 1001 On Fri, 17 Nov 2000, Gunther Birznieks wrote: > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]