SQLite 3.14

Argh! Apologies for autocomplete adding that 'e' to your name!

• Davey

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
  wrote:

Hi Davey!

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

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

Hi Davey!

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

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