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

Reply via email to