Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8634
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: ilia@prohost.org
To: internals@lists.php.net
Date: Fri, 19 Mar 2004 18:18:58 -0500
User-Agent: KMail/1.6.1
References: <61700.66.158.132.127.1079718509.squirrel@www.funio.com> <200403191641.18788.ilia@prohost.org> <61476.66.158.132.127.1079736158.squirrel@www.funio.com>
In-Reply-To: <61476.66.158.132.127.1079736158.squirrel@www.funio.com>
Organization: Prohost.org
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <200403191818.58888.ilia@prohost.org>
Subject: Re: [PHP-DEV] new security related directive for php-4.3.4
From: ilia@prohost.org (Ilia Alshanetsky)

On March 19, 2004 05:42 pm, boulat@funio.com wrote:
> So just because there might be means to bypass security options in PHP we
> shouldnt even bother improving security? Lets give up.

The issue is not the fact that these setting can be bypassed by PHP, those are 
bugs to be fixed. But the fact since the settings are PHP specific, other 
scripting languages (mod_perl|python) and CGI could be used to do actions 
restrictred from PHP. The real solution is in the webserver not a scripting 
language that is being run from inside the webserver.

Ilia