Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95584 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25842 invoked from network); 2 Sep 2016 19:08:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2016 19:08:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.15.18 mout.gmx.net Received: from [212.227.15.18] ([212.227.15.18:62754] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 22/20-19490-23EC9C75 for ; Fri, 02 Sep 2016 15:08:35 -0400 Received: from [192.168.2.103] ([79.243.115.246]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MEnjW-1brUP605LG-00G1md; Fri, 02 Sep 2016 21:08:30 +0200 To: Davey Shafik , Anatol Belski References: <036401d1f30f$afa85a40$0ef90ec0$@belski.net> <3dc2f23a-c4fb-a63d-ab7f-fa841091b313@gmx.de> <53037294-e8ed-31c8-95ef-522e02333e7c@gmx.de> <016101d1fa7a$298a5220$7c9ef660$@belski.net> Cc: "internals@lists.php.net" Message-ID: <1a033870-ea53-a115-a644-3f131ad3d42d@gmx.de> Date: Fri, 2 Sep 2016 21:08:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:q63pB2Cq7jWk60sXW1raOMPkdSe2Bxq7DBQMWBrexAM3DdK6U5K euCPV9+V2iRr117ZevPhRQ8+p61ihePgX0/gpI72t9j7qUC0e4/MGw2k/8pPVbD6VNmh/Hb qmEkW4qYNnfpknLJ6OHf+EQP/Rj7/agGUQubGoM3/WCMiY1oOsF0MBqQsoIoZRqIBw2srs9 Bj275X42OQgjvjutkHIww== X-UI-Out-Filterresults: notjunk:1;V01:K0:5o1xlio0kBw=:eTHpNRtpsxSfoJ4k0d5n5I Fclb04rILjQZMIvf6UnwqeYORgPB9OTm8zdDt6hmdoQDd1kg4IlfccB5GQsWhBAFNLeH+N/qk A+LM4kX9KRoOrJbx/bKtBsqiuVh5ylR+HPgMvlrsrIvd/78DA7yNwNO/2eRE1UFmxQoxIX1a+ 3gOSs3Jx/QQwurJtnnBCVc5odrN6xf0D+tVXSmbhtF28tcLqzoqmNxAXUYoRm+3TpsrZrNb2n eaCGhzBaEVsJIf2a52z+SWsUvQLZh7bPGGTOBaVRmCaS8WdG0vayxYHwlt83SjTjC+AIqToxY ZeO2NlkUy/xEUjTvRsFmU/b8Ir2pPDWisM03Wcfg4LVnMQwM9471BCCtOjvPckOlNBRpmmcpS TkjM1NaH/US+Ru0Cx0HyuEQe3DlhmyoNFgxxP10ODrIScp71xH89UxA7s4+WpYuwtDHhEnC2z OmzKlTV5cztO2lfpOJmLoCkndcac9tdh3L3radYw31QC5kvnFb6giJtz3rIiqTrCZa6kggmtG RYBEV7gsYEVKdoqbOW77Hewe3yjZPhtiPbiCn3KkwSV7lpHe16zQEfrZP4NkC+nOmPg5TYw+l Ss5QAklVIDaDlkflUceGxKtI0GZ1ey6vzFrYXW8eVQ5jVE1j5AxhtVFO5Lm9G0vcs86TCB3WI uW9/lb4YDYkNM2O10VZ2wNA/28lNz1rmC7vhrHZfy73hPy3aoStup6dnPU0P1p/GjDamcD+sH 5+lOAu2+oxy8zqX11xIeAmxS+JSIIy2RcsyRAhc0apvZQ2rS5hFUwYC/8OojNB2h1WibO38Yg GJSAD3I Subject: Re: [PHP-DEV] SQLite 3.14 From: cmbecker69@gmx.de ("Christoph M. Becker") On 31.08.2016 at 05:46, Davey Shafik wrote: > Sorry, I dropped the ball on this one: > > ../sapi/cli/php -d "output_handler=" -d "open_basedir=." -d > "disable_functions=" -d "output_buffering=Off" -d "error_reporting=32767" > -d "display_errors=1" -d "display_startup_errors=1" -d "log_errors=0" -d > "html_errors=0" -d "track_errors=1" -d "report_memleaks=1" -d > "report_zend_debug=0" -d "docref_root=" -d "docref_ext=.html" -d > "error_prepend_string=" -d "error_append_string=" -d "auto_prepend_file=" > -d "auto_append_file=" -d "ignore_repeated_errors=0" -d "precision=14" -d > "memory_limit=128M" -d "log_errors_max_len=0" -d "opcache.fast_shutdown=0" > -d "opcache.file_update_protection=0" -f > "/php-src/ext/sqlite3/tests/sqlite3_21_security.php" > > I think the issue is that the test isn't run in ext/sqlite3/tests, but from > the root of the checkout, which means that open_basedir=. would include > everything in the repo, including the attempt "../bad" directory. Ah, I have not thought of running in a root directory directly (or would have expected that "../bad" would still trigger the open_basedir warning). > Potential solutions: > > Change the path to be "../../../../../bad" to ensure it's outside the > top-level of the script. If "../bad" doesn't trigger the open_basedir restriction, "../../bad" most likely also wouldn't. Please correct me if I'm wrong. > Add a: chdir(__DIR__); at the top. Indeed, using chdir() seems to be the proper way to test for open_basedir restrictions, see . Should that be changed for PHP-5.6+? Cheers! > Thoughts? > > On Fri, Aug 19, 2016 at 5:31 PM, Anatol Belski > wrote: > >> Hi Davey, >> >>> -----Original Message----- >>> From: Davey Shafik [mailto:davey@php.net] >>> Sent: Friday, August 19, 2016 7:09 PM >>> To: Christoph M. Becker >>> Cc: Anatol Belski ; internals@lists.php.net >>> Subject: Re: [PHP-DEV] SQLite 3.14 >>> >>> Christophe, >>> >>> I got the failure multiple times in my Debian Jessie docker container >> that I use >>> for builds - you can check it out yourself at >> https://github.com/dshafik/php-build >>> to see the setup. >>> >>> Thanks for looking into this! >>> >>> - Davey >>> >>> On Sat, Aug 20, 2016 at 01:35 Christoph M. Becker >> > wrote: >>> >>> >>> Hi Davey! >>> >>> On 19.08.2016 at 15:32, Davey Shafik wrote: >>> >>> > I saw this failure while packaging 7.1.0beta3, and assume it >> might be >>> > related to your update: >>> > >>> > FAIL SQLite3 open_basedir checks >>> > [ext/sqlite3/tests/sqlite3_21_security.phpt] >>> > >>> > ========DIFF======== >>> > 006- >>> > 007- Warning: SQLite3::__construct(): open_basedir restriction in >>> effect. >>> > File(%s) is not within the allowed path(s): (.) in >>> > %ssqlite3_21_security.php on line %d >>> > 008- Exception: open_basedir prohibits opening %s in >>> > %ssqlite3_21_security.php:%d >>> > 009- Stack trace: >>> > 010- #0 %ssqlite3_21_security.php(%d): SQLite3->__construct('%s') >>> > 011- #1 {main} >>> > ========DONE======== >>> > >>> > Can you please look into this in time for RC1? >>> >>> I've just checked again with the tagged PHP-7.1.0beta3, but the >> test >>> succeeds on my machine. Therefore it's hard for me to assess what >> is >>> wrong. According to the diff, it appears that the second DB which >>> shouldn't be created according to the open_basedir restriction, is >>> actually successfully created. >>> >>> Anyway, it's rather unlikely that an open_basedir related failure >> is >>> caused by updating SQLite, as this check is part of the PHP >> binding[1], >>> which has not been affected by this commit. The issue might be >> caused >>> by commit cc125f27[2], but that's also somewhat unlikely, because >> the >>> Travis checks usually succeed generally. >>> >>> Can you reproduce the test failure? In which enviroment? >>> >>> [1] > sqlite3 >>> /sqlite3.c#L125 >> 7.1.0beta3/ext/sqlite3/sqlite3.c#L125> > >>> [2] >>> >> I was checking this and saw no failure as well. From the test diff, it >> doesn't look like a crash but something with that try/catch block. Maybe >> there'll be more luck with a reproducer, if you could post the exact >> command line? You can read it from the corresponding .sh file or just by >> appending --verbose. >> >> Regards >> >> Anatol >> >