Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95510
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.179 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <016101d1fa7a$298a5220$7c9ef660$@belski.net>
References: <ce120e4d-a166-e43d-bf36-e756a9241f8f@gmx.de> <036401d1f30f$afa85a40$0ef90ec0$@belski.net>
 <3dc2f23a-c4fb-a63d-ab7f-fa841091b313@gmx.de> <CANaX5ncTdzwVv1Uh6i_d-Yg8ahKOjkJfXBfgRB1-hK3AzatG-w@mail.gmail.com>
 <53037294-e8ed-31c8-95ef-522e02333e7c@gmx.de> <CANaX5ndjKJxJ-GJE=q1OhKMYyoUEP+JWwDDjP+p_4eaPfwYj1Q@mail.gmail.com>
 <016101d1fa7a$298a5220$7c9ef660$@belski.net>
Date: Tue, 30 Aug 2016 20:46:08 -0700
Message-ID: <CANaX5nfgkTey2H+oGdmPU5q1KW2MOgynqMpkuO_pfLfPZf7Uyg@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c05c08a0a9a0a053b55f099
Subject: Re: [PHP-DEV] SQLite 3.14
From: davey@php.net (Davey Shafik)

--94eb2c05c08a0a9a0a053b55f099
Content-Type: text/plain; charset=UTF-8

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 <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
>

--94eb2c05c08a0a9a0a053b55f099--