Re: SQLite 3.14
| From: | Davey Shafik | Date: | Wed, 31 Aug 2016 03:46:08 +0000 |
| Subject: | Re: SQLite 3.14 | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95510@lists.php.net to get a copy of this message | ||
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.php@belski.net>
wrote:
> Hi Davey,
>
> > -----Original Message-----
> > From: Davey Shafik [mailto:davey@php.net]
> > Sent: Friday, August 19, 2016 7:09 PM
> > To: Christoph M. Becker <cmbecker69@gmx.de>
> > Cc: Anatol Belski <anatol.php@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 <cmbecker69@gmx.de
> > <mailto:cmbecker69@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 <ˆÒ)˜K´ÆàO
> > ºñ$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
>