Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:8633 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57897 invoked by uid 1010); 19 Mar 2004 23:01:26 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 57833 invoked from network); 19 Mar 2004 23:01:26 -0000 Received: from unknown (HELO asuka.nerv) (24.100.195.79) by pb1.pair.com with SMTP; 19 Mar 2004 23:01:26 -0000 Received: (qmail 21883 invoked from network); 19 Mar 2004 23:01:25 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 19 Mar 2004 23:01:25 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: internals@lists.php.net Date: Fri, 19 Mar 2004 18:01:31 -0500 User-Agent: KMail/1.6.1 References: <61700.66.158.132.127.1079718509.squirrel@www.funio.com> <200403191709.29446.ilia@prohost.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <200403191801.31596.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:23 pm, Rasmus Lerdorf wrote: > I suppose it could, but it doesn't. Have you tried it? I've tried on a small scale. > But people still like the efficiency and convenience of a runtime > open_basedir check. It gets you 90% of the way there and it doesn't cost > you that much. Until there is a realworld alternative for folks, and no, > nothing mentioned so far are realistic alternatives, I just don't see this > demand going away. I am not suggesting we remove open_basedir or safe_mode although I still maintain they are horrible kludges implemented in the wrong place as it is not the job of scripting language to implement file system security. Adding further hacks, prevents the development of real solutions to the problem rather then hacks trivially bypassed. These open_basedir/safe_mode will not prevent the use of CGI (supported by most IPS) to bypass these limits, INI leaks can be used to bypass those 'security' measures as well, etc... Ultimately the choice to use easy to implement hacks creates a false a sense of security, which ultimately leads to compromised servers. Regardless of who is right or wrong at this point PHP 4 is feature locked and so is PHP 5. Ilia