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

Reply via email to