On 02.09.2016 at 21:21, Davey Shafik wrote: > Good find with that other test! > > I don't see any reason not to fix it for 5.6+
Fine, I'll see to it. Cheers! > - Davey > > On Fri, Sep 2, 2016 at 12:08 PM, Christoph M. Becker <cmbecke...@gmx.de> > wrote: > >> 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 >> <https://github.com/php/php-src/blob/PHP-7.0.11/tests/ >> security/open_basedir.inc#L12-L14>. >> >> Should that be changed for PHP-5.6+? >> >> Cheers! >> >>> Thoughts? >>> >>> On Fri, Aug 19, 2016 at 5:31 PM, Anatol Belski <anatol....@belski.net> >>> wrote: >>> >>>> Hi Davey, >>>> >>>>> -----Original Message----- >>>>> From: Davey Shafik [mailto:da...@php.net] >>>>> Sent: Friday, August 19, 2016 7:09 PM >>>>> To: Christoph M. Becker <cmbecke...@gmx.de> >>>>> Cc: Anatol Belski <anatol....@belski.net>; 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 <cmbecke...@gmx.de >>>>> <mailto:cmbecke...@gmx.de> > 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] <https://github.com/php/php-src/blob/PHP-7.1.0beta3/ext/ >>>> sqlite3 >>>>> /sqlite3.c#L125 <https://github.com/php/php-src/blob/PHP- >>>>> 7.1.0beta3/ext/sqlite3/sqlite3.c#L125> > >>>>> [2] <https://github.com/php/php-src/commit/cc125f27> >>>>> >>>> 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 >>>> >>> >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
