On Sun, 13 Jan 2002, Daniel Lorch wrote: > Hi, > > > There are plenty of ways to make PHP secure for virtual hosting. I > > personally prefer a separate Apache instance for each virtualhost where > > each instance runs as that customer's own UNIX user id. Then standard > > Linux filesystem security can be applied. > > We were thinking of that possibility. We would be running an apache > process which only delegates all requests to each customer's apache. > We would use mod_rewrite to accomplish this. > > But this really would mean a serious impact on performance and also > terribly much of work to set up an apache for every single customer.
There is also mod_become, which allows apache to swap to the user on a vhost base. http://www.snert.com/Software/mod_become/index.shtml Our sysadm wrote some additions to it (I dunno what precisely), which shouls have made it more secure. > > And it doesn't make sense to me. > > > A nice way to achieve this is to use a reverse proxy such as Squid out in > > front of your external port 80 and have something like SquidGuard direct > > requests to different ips/ports for the various virtual hosts. You get > > the added benefit of actually getting a fast cache sitting out in front of > > all your dynamic pages which speeds things up considerably. > > .. and what I absolutely don't wish to have. I cannot access variables > such as $REMOTE_ADDR within a script behind a cache and I pretty much > like being in control of output-buffering and caching myself. > > > As far as I am concerned this is best way. But, you can also get pretty > > far with the standard open_basedir approach. I am a bit dismayed to hear > > you say that setting open_basedir for each virtualhost is a lot of work. > > Surely this is a 10-second awk script or even a vi macro that simply > > takes: > > > DOCUMENT_ROOT /some/path > > > and turns it into: > > > DOCUMENT_ROOT /some/path > > php_admin_value open_basedir /some/path > > .. and you could also write a PHP script which does this. But that's > not the point. you start delegating things to PHP for which it was > never built for. I don't know much about UN*X but the one thing I > learned was: modularity. With mod_php you have to take care of things > which it was never designed for, such as check file permissions etc.. > > I absolutely cannot understand how you can recommend people to use > mod_php for virtual hosting. I absolutely LOVE PHP, but mod_php is > ugly. I think this is just about making PHP more popular, because > *everyone* can install the module. Doing it right requires more > knowledge and skills. Everything has to be RAD, but nobody thinks > about SAD (security ..) Would you recommend the CGI then? And adding a big performance hit? IMO, mod_php works just fine (if something like mod_become is implemented, along with the safe_mode restrictions). Derick -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
