Re: Re: cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

From: Date: Mon, 06 Aug 2001 22:20:57 +0000
Subject: Re: Re: cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
References: 1 2 3 4 5 6 7 8  Groups: php.dev 
Request: Send a blank email to php-dev+get-62362@lists.php.net to get a copy of this message 
I disagree in two levels.  First, I think that saying "We can't protect people from their stupidity, so let's lift all bars" is just plain wrong and a bad approach in a real world situation.  Sure, it's true, but we can definitely reduce the risks involved in common mistakes that people make.  Not bulletproof, but sometimes simply hinting people not to go around places where shots are fired is good enough.

On the second level, there are several other reasons not to keep dl() which aren't related to security or preventing people from doing the wrong things.  These are:
- Slow performance, encourages slow app writing
- Complicates the development of extensions and the engine
- Will not work in thread safe mode

All in all, dl() is simply bad, in just about every level.

Zeev

At 00:03 07-08-01, George Schlossnagle wrote:

In a few words:
For a webserver: ban dl()
For generic scripting: keep dl()

What's really the point of protecting people from their stupidity.  If
you're going to keep it in the generic scripting engine (which I think has
lots of value), why not keep it in the webserver engine as well. There are
plenty of php extensions which, imho, operate way to slow to called on a
busy production site.  Does that mean they should be eliminated?  No, it
means they should just be used with a 'buyer-beware' mentality.

George


--
Zeev Suraski <zeev@zend.com>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/

Thread (52 messages)

« previous php.dev (#62362) next »