Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95588
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender)
To: Davey Shafik <davey@php.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>
 <CANaX5nfgkTey2H+oGdmPU5q1KW2MOgynqMpkuO_pfLfPZf7Uyg@mail.gmail.com>
 <1a033870-ea53-a115-a644-3f131ad3d42d@gmx.de>
 <CANaX5ndH-WX+OkWOixCRxP7bHqfdsoubDScngY4Fe3UhHv7ZBg@mail.gmail.com>
Cc: Anatol Belski <anatol.php@belski.net>,
 "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <4698e7d4-ffa5-af15-a231-0c2bdeb52605@gmx.de>
Date: Fri, 2 Sep 2016 21:50:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CANaX5ndH-WX+OkWOixCRxP7bHqfdsoubDScngY4Fe3UhHv7ZBg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] SQLite 3.14
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 02.09.2016 at 21:21, Davey Shafik wrote:

> Good find with that other test!
> 
> I don't see any reason not to fix it for 5.6+

Fine, I'll see to it.

Cheers!

> - Davey
> 
> On Fri, Sep 2, 2016 at 12:08 PM, Christoph M. Becker <cmbecker69@gmx.de>
> 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 <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
>>>>
>>>
>>
>