Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74969 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85661 invoked from network); 18 Jun 2014 06:05:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jun 2014 06:05:54 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.67] ([108.166.43.67:34253] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5B/A2-01877-14C21A35 for ; Wed, 18 Jun 2014 02:05:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id CFB5C3820E3; Wed, 18 Jun 2014 02:05:50 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 82A533820B7; Wed, 18 Jun 2014 02:05:50 -0400 (EDT) Message-ID: <53A12C3D.1060808@sugarcrm.com> Date: Tue, 17 Jun 2014 23:05:49 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pierre Joye CC: PHP internals References: <53A10C5B.1000003@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHP6, drop open_basedir? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > It gives a false sense of safety, and that alone for me is a good > enough reason to remove it. it is not as bad as safe_mode but simply > not good. If you use it right, it does not. Every security feature would give you false sense of safety if you use it wrong - but that alone is not the reason to not have it at all, if it has legitimate uses. IMO open_basedir does. > That being said I have no issue with keeping it besides the lost > opportunity to get rid of an old bad decision. Bad decision was to brand open_basedir as security function that allows defense against attacker with PHP code execution rights. It is obvious we can not deliver on this promise. However, it does not mean that used differently - e.g. as a safeguard in your own code to not access things that you don't want this code to access by mistake - it can not be used. I think it can. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227