Hi, >> 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. You're right. mod_rewrite was just an idea, but it would run better with a proxy. >> .. 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. good idea. >> .. 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. I did read it. Very carefully and not only once. Did you read MY reponse carefully? What you are saying now is exactly what I'm trying to say (and I think I actually did. The thing about modularity). All this should *NOT* be handled by PHP but it still _IS_ and you (not specificly you, rasmus, but some of the developers) recommend using mod_php for virtual hosting. The only thing I'm talking about is: mod_php (+ safe_mode) != virtual hosting it should be php cgi (+ safe_mode) == virtual hosting and mod_php == own, private box. performance boost. Does anyone have experience with the CGIWrap patch for PHP? It looks like a good thing: http://www.klaban.torun.pl/patches/cgiwrap/ > 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. We could also run an own virtual machine with it's own kernel for every customer to provide maximum security. I'm not saying it's not possible, but this is not a *CLEAN* solution. What you are suggesting me is a workaround, nothing more. There is nothing on php.net about your solution, so you must admit it's not a standard solution. >> > 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. PHP cannot circumvent the unix file permissions. If our apache (www-data) is able to LIST /tmp/ then every user is able to do the same thing within a PHP script - logically. This has nothing to do with safe_mode. /etc/ also belongs to root, but I'm still able to look into it, because there is a o+rx on that directory. Or did we configure something wrong? We are using debian and apache is www-data. 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]
