Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95585 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29583 invoked from network); 2 Sep 2016 19:21:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2016 19:21:18 -0000 Authentication-Results: pb1.pair.com smtp.mail=me@daveyshafik.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=me@daveyshafik.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.175 cause and error) X-PHP-List-Original-Sender: me@daveyshafik.com X-Host-Fingerprint: 209.85.220.175 mail-qk0-f175.google.com Received: from [209.85.220.175] ([209.85.220.175:32826] helo=mail-qk0-f175.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F5/80-19490-C21D9C75 for ; Fri, 02 Sep 2016 15:21:16 -0400 Received: by mail-qk0-f175.google.com with SMTP id z190so130262770qkc.0 for ; Fri, 02 Sep 2016 12:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daveyshafik-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3MhN3ZS+s5kV70RfP1oHIincbQ6mFKEC+PhQHYR87NU=; b=p6sGKSONCKnYI45Bhnu95MJJH0kcg+j6BxadKilDFjerMp28WTBtzgf9clH5BoskbU tonXc13IlUjLGYOXxJeIpz2ZhMNzUAbQ0DRbGhck/WpX0Ar5xrmsVAiWJPC4JNNjRqo1 RTynUl5H5HUae0qjeyN62hRt8p2BJkVnDcU90fPmAEo+htqmGXxHvesUyeihYPYOIHqv mP0SCKhKLWFeOj1CCq8TIC/gpXI60He8cvMn4/xTUvifxYa3tpzwWgwse8DmUgfXMHnS xSAdjmD0ujyFEAHOCnQWWIkQr/fMyqdRbzzmkl+4Uq1+R8rdJkR+fCHlpHi3kamCUtWS MSDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3MhN3ZS+s5kV70RfP1oHIincbQ6mFKEC+PhQHYR87NU=; b=bowg1cdx8DWnUHLz/pE8ZquOzF+kEB5PcTGb2tRdIjlDyCoXKI67SKdZ0q6Dl+Ue/L DJenWoAUdtjO6wHogGUAJG+x18DO0iELD2MJTQ9Z+jWoIRtwyHwOJvnBCCY2mK9NcKNc Rb8V3Cc3L+MeShuUL4ztLF1yfFueXTnvJzvYFtHvECtZ7MTscjwnOLhcilN1BPISZ5Dj aL5CxwAuItafEcD0K0BeySRaYgnsTEF8DgctYYje4tzzG4GU/l2nJY7LIODtW8UN66TC YAEPz8s96Pj9KCTPgYlSKr5aBdTB1cbuTB8zSpFcjuEhZHibv/e5tXSLvbKYUBXCunHU NDmw== X-Gm-Message-State: AE9vXwMpehaS/90ozoAMhTWS9mxi43GS2JLSyoBtKa1JlRIeUB+IKgcNFNctGwLayokWBNPsCForJ2PNF/mMRkEW X-Received: by 10.55.156.85 with SMTP id f82mr2713637qke.152.1472844073314; Fri, 02 Sep 2016 12:21:13 -0700 (PDT) MIME-Version: 1.0 Sender: me@daveyshafik.com Received: by 10.237.55.138 with HTTP; Fri, 2 Sep 2016 12:21:12 -0700 (PDT) In-Reply-To: <1a033870-ea53-a115-a644-3f131ad3d42d@gmx.de> References: <036401d1f30f$afa85a40$0ef90ec0$@belski.net> <3dc2f23a-c4fb-a63d-ab7f-fa841091b313@gmx.de> <53037294-e8ed-31c8-95ef-522e02333e7c@gmx.de> <016101d1fa7a$298a5220$7c9ef660$@belski.net> <1a033870-ea53-a115-a644-3f131ad3d42d@gmx.de> Date: Fri, 2 Sep 2016 12:21:12 -0700 X-Google-Sender-Auth: xFKpe4Kmk5USsfeBcpu7gK-s39g Message-ID: To: "Christoph M. Becker" Cc: Anatol Belski , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a114fb310cccb33053b8b3b8a Subject: Re: [PHP-DEV] SQLite 3.14 From: davey@php.net (Davey Shafik) --001a114fb310cccb33053b8b3b8a Content-Type: text/plain; charset=UTF-8 Good find with that other test! I don't see any reason not to fix it for 5.6+ - Davey On Fri, Sep 2, 2016 at 12:08 PM, Christoph M. Becker 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 > 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 > > wrote: > > > >> Hi Davey, > >> > >>> -----Original Message----- > >>> From: Davey Shafik [mailto:davey@php.net] > >>> Sent: Friday, August 19, 2016 7:09 PM > >>> To: Christoph M. Becker > >>> Cc: Anatol Belski ; 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 >>> > 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] >> sqlite3 > >>> /sqlite3.c#L125 >>> 7.1.0beta3/ext/sqlite3/sqlite3.c#L125> > > >>> [2] > >>> > >> 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 > >> > > > --001a114fb310cccb33053b8b3b8a--