Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86301 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25823 invoked from network); 19 May 2015 11:27:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 May 2015 11:27:30 -0000 Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.17.21 mout.gmx.net Received: from [212.227.17.21] ([212.227.17.21:63523] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/B5-13816-02E1B555 for ; Tue, 19 May 2015 07:27:29 -0400 Received: from [192.168.0.101] ([88.134.68.210]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MU0U9-1YlhYC1Vzd-00Qhar for ; Tue, 19 May 2015 13:27:25 +0200 Message-ID: <555B1E1E.6010903@gmx.de> Date: Tue, 19 May 2015 13:27:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: internals Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ucPNggOeW8idQy7V3txotS9/KGUafpMmuzviNulmHeE2Oaw+zT7 EbSiuQjJS61PiKJ1j/FEQmyRaYCRCIflDvcc4W4qtw+D7SRjQpHUOQ9TBqNh5V0Ox3AvXO0 Bc9CVfWOaWtlW1RSE83ihCMyCo4e11LiAhhHsIV2X19vMu76xE2CMjj3Qvq9l9xseuARhZ8 QFpUEJPay9gX98rLPJARA== X-UI-Out-Filterresults: notjunk:1; Subject: Spurious open_basedir warning From: cmbecker69@gmx.de (Christoph Becker) Hello Internals, there are several bug reports related to open_basedir and non-existant files/directories.[1] uramihsayibok's comment on bug #53041 sheds some light on the issue. A few weeks ago I had a closer look at it, and it seems that using expand_filepath_with_mode() instead of expand_filepath() in php_check_specific_open_basedir() would fix the bug (see my patch[2]). I am, however, not sure whether that might have security implications. Could one of the experienced developers please have a look at the issue? Apparently, the spurious open_basedir warning is confusing, and it's something that is often encountered. [1] [2] -- Christoph M. Becker