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. 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 ..) > 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. And I think there is a bug in readdir(), I'll check this and send a bug report if it's true. > In the end this entire problem needs to be solved at the web server level, > not at the PHP level. Apache 2.0 will eventually have per-virtualhost > user/group directives but we are still not quite there with it in terms of > being a production-quality environment. I heard of that and I'm waiting for 2.0 being production quality very impatiently. The only advantage of mod_php over "running PHP as the user" is, that the home directories are "write protected" (because apache only has read permissions). so customers have to take care of developing securely, or someone might wipe their homedir. I quite often see things like that: index.php?site=bla.txt and inside the script: include($site); Silly. But better compromise the security of a customer than compromising the whole server's security. Kind Regards, Daniel Lorch http://daniel.lorch.cc/ -- @echo "Hello, World"; -- 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]
