Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Recieved: (qmail 7154 invoked by uid 0); 19 Mar 2004 22:37:14 -0000
Message-ID: <61476.66.158.132.127.1079736158.squirrel@www.funio.com>
In-Reply-To: <200403191641.18788.ilia@prohost.org>
References: <61700.66.158.132.127.1079718509.squirrel@www.funio.com>
    <200403191609.28127.ilia@prohost.org>
    <63849.66.158.132.127.1079731711.squirrel@www.funio.com>
    <200403191641.18788.ilia@prohost.org>
Date: Fri, 19 Mar 2004 17:42:38 -0500 (EST)
To: ilia@prohost.org
Cc: internals@lists.php.net
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] new security related directive for php-4.3.4
From: boulat@funio.com

> On March 19, 2004 04:28 pm, boulat@funio.com wrote:
>> So then following your logic why not remove open_basedir,safe_mode,etc
>> all
>> together from PHP, just to increase the performance?
>
> Because it would break BC. When these options were developed Apache 2 was
> not around and fastcgi support was flimsy at best.

Ilia as far as Im concerned Apache 2 MPM does not currently work on most
platforms http://httpd.apache.org/docs-2.0/mod/perchild.html
thus unfortunatelly MPM can not be used in production environment.

> Using plain CGI (which MANY
> ISPs use) to run PHP is quite resource intensive.

Which is exactly why I dont use plain CGI to run PHP.

> Popularity of PHP will not be affected by these features and the
> robustness
> would only take a step backwards. More over the 'security' you add is
> easily
> bypassed through a variety of means.

So just because there might be means to bypass security options in PHP we
shouldnt even bother improving security? Lets give up.

IMHO it should be the other way around, we should try to improve security
the best way possible, especially knowing that at the moment there might
be ways of bypassing it.

> Adding more to these
> 'features' when real support is already avaliable seems highly counter
> productive IMO.
>
> Ilia

Cheers,
Boulat