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. Potential solutions: Change the path to be "../../../../../bad" to ensure it's outside the top-level of the script. Add a: chdir(__DIR__); at the top. 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 >
