Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95327
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 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>
Cc: Anatol Belski <anatol.php@belski.net>,
 "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <bffb8c95-ef9a-8528-d326-6f73cdd914a8@gmx.de>
Date: Fri, 19 Aug 2016 21:31:49 +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: <CANaX5ndjKJxJ-GJE=q1OhKMYyoUEP+JWwDDjP+p_4eaPfwYj1Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] SQLite 3.14
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 19.08.2016 at 19:09, Davey Shafik wrote:

> 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!

Of course!  And thanks for the link to your docker container.

I've tried to reproduce the test failure in a similar environment, but
the test always passed.  I've also reviewed the latest commits to
ext/sqlite3/sqlite3.c, but I couldn't find anything that might have
caused the regression.  I'm at a loss – would it be possible to augment
the test with some hopefully helpful diagnostic messages and a check
whether touch()ing this filename would fail?  I mean something like this:

 ext/sqlite3/tests/sqlite3_21_security.phpt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ext/sqlite3/tests/sqlite3_21_security.phpt
b/ext/sqlite3/tests/sqlite3_21_security.phpt
index f28c736..b8962a8 100644
--- a/ext/sqlite3/tests/sqlite3_21_security.phpt
+++ b/ext/sqlite3/tests/sqlite3_21_security.phpt
@@ -18,6 +18,8 @@ unlink($directory . $file);
 echo "Above test directory\n";
 try {
 	$db = new SQLite3('../bad' . $file);
+	var_dump($db, getcwd(), $file, realpath('../bad' . $file));
+	touch('../bad' . $file);
 } catch (Exception $e) {
 	echo $e . "\n";
 }

If it would be too much work for you to test a modified version, this
patch might be committed to PHP 7.0 (the code is dead code anyway, if
the test succeeds), and maybe removed later.

BTW: do you deliberately run the tests without -n in
<https://github.com/dshafik/php-build/blob/master/build.sh#L294>?

Regards,
Christoph

> - Davey
> On Sat, Aug 20, 2016 at 01:35 Christoph M. Becker <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>
>>
>> --
>> Christoph M. Becker
>>
>