> > 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. > > And it doesn't make sense to me.
Makes a whole lot of sense to me, and the Squid reverse-proxy approach is much stronger than Apache/mod_rewrite. > > 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. Well, it is available as $HTTP_X_FORWARDED_FOR instead. Not a big deal. You could map it automatically if you really wanted it as $REMOTE_ADDR instead. > .. 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 ..) Did you read my response at all? The right way to solve this is to not solve it at the PHP level, but at the web server level and run scripts as their correct user ids. The right way to do this with Apache-1.3.x is to use multiple instances. The only real issue is that you need to be quite organized with how you handle your .conf files, but most large virtual hosting configs use separate .conf files for each virtualhost already, so that really doesn't change things very much. Resource-wise it is a lot less expensive than you think. UNIX systems are very good at running many copies of the same executable and sharing pages between them. > > I also don't understand your readdir() issue. opendir() checks safe_mode > > and readdir() needs an opendir()-returned directory identifier to do > > anything. So unless your UNIX filesystem perms are completely wrong, you > > should not be able to write a filebrowser in PHP that goes through > > everyones' directories. Just like you would not be able to read the names > > of the session files in /tmp. > > Depends on whether you have set +r on this directory or not. No it doesn't. safe_mode doesn't check +r, it looks at the user and group ids that own the directory. +r is irrelevant. -Rasmus -- 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]
