On Sat, 2002-05-11 at 19:27, Zeev Suraski wrote: > At 20:17 11/05/2002, Rasmus Lerdorf wrote: > > > Ideally every ISP would use it and each virtual host would have such a > > > directory. In reality I've set to see a SINGLE ISP that has used that > > option. > > > In fact I didn't know about it myself until you told me about on IRC. > > > >Well, it is well documented. The ignorance and stupidity of many ISP's is > >just a fact of life. I am a firm believer in Darwinism amongst ISP's and > >figure the really stupid ones will eventually die off. I am not going to > >go out an actively shoot them though, because that might be illegal. > > Do we have any sort of an PHP-ISP-HOWTO? If not, are there any volunteers > to write one? I think it may be a good idea, because Darwinism goes both > ways - if too many people get bitten by PHP, they'll switch to other solutions. > > Zeev >
hey all, I'm working at Lycos Europe (nothing to do with Lycos, inc, except for the trademark). We do have a large shared hosting service (both free and paid) over 8 countries. That's Millions of webpages. ALl of them able to use php. I've been working on the PHP4U service (as we call it :)) for almost 2 years now on and off (it started with the MultiMania PHP4U Service a while back before being trasnfered to Lycos Hosting), mainly upgrading to the new php version as soon as i considered it robust. I've definitely come over troubles these past 2 years, Zeev can tell, i've been bugging him with questions since then. The php distribution we first used was a 4.0.4pl1. And I had to patch it to cover our needs and cover some safe_mode security bugs. (Those bugs are now corrected since 4.1.2). I also had to patch other little security bugs we found while the service was rolling and the users were reporting it to us. The solution we've chosen is to have a cgi php binary instead of a module for security stuff. The main reason to do so was to have the user-created file have the user's uid. We had to suid the php binary and setuid() the process to the script's uid, of course. This seemed like a good security trouble-keeper (I know some people will say that setuid scripts and security in the same sentence usually ain't a good mix'n'match but .. :) ) since this let the filesystem take care of file permissions which seemed to me the most secure way, Ain't it ? Maybe the Open_basedir solution is a better one although i like the idea of files really owned by the user and not only "virtually". The drawback on the cgi php binary is performance. We have lotsa trouble with php cgi binary not dying after the max_execution_time and stayin' alive on the machines. So we have to terminate them frequently. This has been reported I think a while back and said to be solved but looks like we have an environment that's unique in terms of number of requests per second and load averages, and that not a lot of people can use to test. So people might have the "dead binaries sleeping around" bug solved, but we don't. Ilia, the scripts you talk about that eat up process, cpu, file pointers etc are very interesting, we've already gone against most of them except for the file handlers Attack. Never had that but I think i'm gonna talk about this with our NOC team cause it could be a very big issue now that's it's in the open :) Seriously, i've been surprised as to how low was the number of people trying to hack our system thru PHP. I was really afraid it would far worse, but this might not be the case everywhere, and we still have to be vigilant about all that security stuff. I too think that safe_mode is not a good thing and that open_basedir seems better and more secure. I'm willing to help on a PHP-ISP-Howto document even though but since i've never done such a thing, i'm not sure i can really do something good, Plus we might not have taken the best way of doing things around here. If anybody has comments and or solutions, I'm interested. Later Chand -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
