Good find with that other test!
I don't see any reason not to fix it for 5.6+
- Davey
On Fri, Sep 2, 2016 at 12:08 PM, Christoph M. Becker <[email protected]>
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 <[email protected]>
> > wrote:
> >
> >> Hi Davey,
> >>
> >>> -----Original Message-----
> >>> From: Davey Shafik [mailto:[email protected]]
> >>> Sent: Friday, August 19, 2016 7:09 PM
> >>> To: Christoph M. Becker <[email protected]>
> >>> Cc: Anatol Belski <[email protected]>; [email protected]
> >>> 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 <[email protected]
> >>> <mailto:[email protected]> >
> >>> 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
> >>
> >
>