FAQ
Hello all,

My team is interested in permitting .user.ini files to load
extensions. We believe this to be a simple fix: add
an invocation of php_ini_register_extensions to the end
of sapi/cgi/cgi-main.c.

I don't believe this steps on any invariants, since extensions
can usually be loaded arbitrarily late.

Let me know what the list thinks. I can submit a patch and tests
if y'all decide it's a good idea.

Cheers,
Edward

Search Discussions

  • Rasmus Lerdorf at Nov 8, 2011 at 8:40 am

    On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
    Hello all,

    My team is interested in permitting .user.ini files to load
    extensions. We believe this to be a simple fix: add
    an invocation of php_ini_register_extensions to the end
    of sapi/cgi/cgi-main.c.

    I don't believe this steps on any invariants, since extensions
    can usually be loaded arbitrarily late.

    Let me know what the list thinks. I can submit a patch and tests
    if y'all decide it's a good idea.
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.

    -Rasmus
  • Edward Z. Yang at Nov 8, 2011 at 8:46 am

    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.
    Yep. If you like, I can make it so that it only applies for CGI
    requests, not FastCGI requests.

    Cheers,
    Edward
  • Rasmus Lerdorf at Nov 8, 2011 at 8:55 am

    On 11/08/2011 12:46 AM, Edward Z. Yang wrote:
    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.
    Yep. If you like, I can make it so that it only applies for CGI
    requests, not FastCGI requests.
    It should match the dl() SAPI availability.

    -Rasmus
  • Edward Z. Yang at Nov 8, 2011 at 9:03 am

    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:54:56 -0500 2011:
    It should match the dl() SAPI availability.
    OK, can do!

    Cheers,
    Edward
  • Yasuo Ohgaki at Nov 8, 2011 at 9:27 am
    It seems working on my MacBook.
    I just tried php-src-5.4 with


    $ uname -a
    Darwin esi-yasmc1.esi.local 10.8.0 Darwin Kernel Version 10.8.0: Tue
    Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
    $./configure && make

    and got following result.

    $ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/php -v
    ==63465== Memcheck, a memory error detector
    ==63465== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
    ==63465== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
    ==63465== Command: ./sapi/cli/php -v
    ==63465==
    --63465-- ./sapi/cli/php:
    --63465-- dSYM directory is missing; consider using --dsymutil=yes
    PHP 5.4.0RC1-dev (cli) (built: Nov 8 2011 18:19:07)
    Copyright (c) 1997-2011 The PHP Group
    Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
    ==63465==
    ==63465== HEAP SUMMARY:
    ==63465== in use at exit: 104,661 bytes in 8 blocks
    ==63465== total heap usage: 13,688 allocs, 13,680 frees, 2,936,131
    bytes allocated
    ==63465==
    ==63465== LEAK SUMMARY:
    ==63465== definitely lost: 0 bytes in 0 blocks
    ==63465== indirectly lost: 0 bytes in 0 blocks
    ==63465== possibly lost: 0 bytes in 0 blocks
    ==63465== still reachable: 104,661 bytes in 8 blocks
    ==63465== suppressed: 0 bytes in 0 blocks
    ==63465== Rerun with --leak-check=full to see details of leaked memory
    ==63465==
    ==63465== For counts of detected and suppressed errors, rerun with: -v
    ==63465== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

    However, I got this with bash

    $ valgrind bash
    ==63473== Memcheck, a memory error detector
    ==63473== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
    ==63473== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
    ==63473== Command: bash
    ==63473==
    ==63473== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
    ==63473== the SIGUSR2 signal is used internally by Valgrind
    --63473:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
    --63473:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );


    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net


    On Tue, Nov 8, 2011 at 6:03 PM, Edward Z. Yang wrote:
    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:54:56 -0500 2011:
    It should match the dl() SAPI availability.
    OK, can do!

    Cheers,
    Edward

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Edward Z. Yang at Nov 11, 2011 at 3:15 am
    Here is the proposed patch (sans tests; we did our own manual testing
    on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
    tests when you say so):

    http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.

    Edward

    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
    On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
    Hello all,

    My team is interested in permitting .user.ini files to load
    extensions. We believe this to be a simple fix: add
    an invocation of php_ini_register_extensions to the end
    of sapi/cgi/cgi-main.c.

    I don't believe this steps on any invariants, since extensions
    can usually be loaded arbitrarily late.

    Let me know what the list thinks. I can submit a patch and tests
    if y'all decide it's a good idea.
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.

    -Rasmus
  • Christopher Jones at Nov 11, 2011 at 7:28 pm

    On 11/10/2011 07:14 PM, Edward Z. Yang wrote:

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.
    What about logging a bug for that specific change so it doesn't get lost, and so
    it can be tracked?

    Chris

    --
    Email: christopher.jones@oracle.com
    Tel: +1 650 506 8630
    Blog: http://blogs.oracle.com/opal/
  • Edward Z. Yang at Nov 11, 2011 at 7:32 pm
    Well, I'm kind of hoping this patch will go in, so we don't have to bother
    with a bug. I can if you really want me to.

    Cheers,
    Edward

    Excerpts from Christopher Jones's message of Fri Nov 11 14:28:30 -0500 2011:
    On 11/10/2011 07:14 PM, Edward Z. Yang wrote:

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.
    What about logging a bug for that specific change so it doesn't get lost, and so
    it can be tracked?

    Chris
  • Will Fitch at Nov 11, 2011 at 7:36 pm
    You should always tie a patch to a bug/feature request. Need to know/remember why the patch was applied in the first place.
    On Nov 11, 2011, at 2:32 PM, Edward Z. Yang wrote:

    Well, I'm kind of hoping this patch will go in, so we don't have to bother
    with a bug. I can if you really want me to.

    Cheers,
    Edward

    Excerpts from Christopher Jones's message of Fri Nov 11 14:28:30 -0500 2011:
    On 11/10/2011 07:14 PM, Edward Z. Yang wrote:

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.
    What about logging a bug for that specific change so it doesn't get lost, and so
    it can be tracked?

    Chris
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Rasmus Lerdorf at Nov 11, 2011 at 7:38 pm
    Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk

    It is short and simple so I could do it manually, of course, but I'd
    like to know what you have been testing it against.
    On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
    Here is the proposed patch (sans tests; we did our own manual testing
    on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
    tests when you say so):

    http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.

    Edward

    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
    On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
    Hello all,

    My team is interested in permitting .user.ini files to load
    extensions. We believe this to be a simple fix: add
    an invocation of php_ini_register_extensions to the end
    of sapi/cgi/cgi-main.c.

    I don't believe this steps on any invariants, since extensions
    can usually be loaded arbitrarily late.

    Let me know what the list thinks. I can submit a patch and tests
    if y'all decide it's a good idea.
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.

    -Rasmus
  • Edward Z. Yang at Nov 11, 2011 at 7:42 pm
    http://svn.php.net/repository/php/php-src/branches/PHP_5_3
    r318957

    We also applied it to 5.3.8 release, although we had to fix up the patch
    for that. I can port it to 5.4.

    Edward

    Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
    Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk

    It is short and simple so I could do it manually, of course, but I'd
    like to know what you have been testing it against.
    On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
    Here is the proposed patch (sans tests; we did our own manual testing
    on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
    tests when you say so):

    http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.

    Edward

    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
    On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
    Hello all,

    My team is interested in permitting .user.ini files to load
    extensions. We believe this to be a simple fix: add
    an invocation of php_ini_register_extensions to the end
    of sapi/cgi/cgi-main.c.

    I don't believe this steps on any invariants, since extensions
    can usually be loaded arbitrarily late.

    Let me know what the list thinks. I can submit a patch and tests
    if y'all decide it's a good idea.
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.

    -Rasmus
  • Rasmus Lerdorf at Nov 11, 2011 at 8:45 pm
    Well, it is simple enough that we don't really need a patch. However,
    generally if you want to submit a patch it needs to be against a current
    svn branch and not an old release. You want to minimize the work people
    will need to do to look at your suggested change.

    The other issue with your patch is that you are enabling this for the
    fpm sapi. I thought we agreed that this should only be in the sapis that
    supported dl() and those are cgi, cli and embed. And .user.ini doesn't
    apply to embed, so it would just be cli and cgi because these are the
    non-persistent cases where there is no danger of screwing up the next
    request with a bad extension in a .user.ini file.

    -Rasmus
    On 11/11/2011 11:42 AM, Edward Z. Yang wrote:
    http://svn.php.net/repository/php/php-src/branches/PHP_5_3
    r318957

    We also applied it to 5.3.8 release, although we had to fix up the patch
    for that. I can port it to 5.4.

    Edward

    Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
    Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk

    It is short and simple so I could do it manually, of course, but I'd
    like to know what you have been testing it against.
    On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
    Here is the proposed patch (sans tests; we did our own manual testing
    on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
    tests when you say so):

    http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.

    Edward

    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
    On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
    Hello all,

    My team is interested in permitting .user.ini files to load
    extensions. We believe this to be a simple fix: add
    an invocation of php_ini_register_extensions to the end
    of sapi/cgi/cgi-main.c.

    I don't believe this steps on any invariants, since extensions
    can usually be loaded arbitrarily late.

    Let me know what the list thinks. I can submit a patch and tests
    if y'all decide it's a good idea.
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.

    -Rasmus
  • Pierre Joye at Nov 11, 2011 at 9:42 pm
    hi,
    On Fri, Nov 11, 2011 at 9:45 PM, Rasmus Lerdorf wrote:

    The other issue with your patch is that you are enabling this for the
    fpm sapi. I thought we agreed that this should only be in the sapis that
    supported dl() and those are cgi, cli and embed. And .user.ini doesn't
    apply to embed, so it would just be cli and cgi because these are the
    non-persistent cases where there is no danger of screwing up the next
    request with a bad extension in a .user.ini file.
    Right, that's what I worry about this patch. I would not introduce
    this patch for anything but where dl is available.

    Cheers,
  • Edward Z. Yang at Nov 11, 2011 at 9:43 pm

    Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011:
    Well, it is simple enough that we don't really need a patch. However,
    generally if you want to submit a patch it needs to be against a current
    svn branch and not an old release. You want to minimize the work people
    will need to do to look at your suggested change. Gotcha.
    The other issue with your patch is that you are enabling this for the
    fpm sapi. I thought we agreed that this should only be in the sapis that
    supported dl() and those are cgi, cli and embed. And .user.ini doesn't
    apply to embed, so it would just be cli and cgi because these are the
    non-persistent cases where there is no danger of screwing up the next
    request with a bad extension in a .user.ini file.
    Hmm, it looks like cli doesn't have .user.ini support at all. Does this
    mean we should implement .user.ini for these SAPIs? I'd be in favor.

    Edward
    -Rasmus
    On 11/11/2011 11:42 AM, Edward Z. Yang wrote:
    http://svn.php.net/repository/php/php-src/branches/PHP_5_3
    r318957

    We also applied it to 5.3.8 release, although we had to fix up the patch
    for that. I can port it to 5.4.

    Edward

    Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
    Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk

    It is short and simple so I could do it manually, of course, but I'd
    like to know what you have been testing it against.
    On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
    Here is the proposed patch (sans tests; we did our own manual testing
    on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
    tests when you say so):

    http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch

    The change to zlist_clean is necessary because otherwise extension_lists can't
    be reused for the second round of extension appliations (since the head and
    tail pointers have garbage in them). You should probably take that fix regardless
    of what you think of the feature change.

    Edward

    Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
    On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
    Hello all,

    My team is interested in permitting .user.ini files to load
    extensions. We believe this to be a simple fix: add
    an invocation of php_ini_register_extensions to the end
    of sapi/cgi/cgi-main.c.

    I don't believe this steps on any invariants, since extensions
    can usually be loaded arbitrarily late.

    Let me know what the list thinks. I can submit a patch and tests
    if y'all decide it's a good idea.
    You are aware that these extensions can't be unloaded, right? So one
    user loading an extension will potentially be stepping on another user
    and breaking their code.

    -Rasmus
  • Pierre Joye at Nov 11, 2011 at 9:44 pm

    On Fri, Nov 11, 2011 at 10:43 PM, Edward Z. Yang wrote:

    The other issue with your patch is that you are enabling this for the
    fpm sapi. I thought we agreed that this should only be in the sapis that
    supported dl() and those are cgi, cli and embed. And .user.ini doesn't
    apply to embed, so it would just be cli and cgi because these are the
    non-persistent cases where there is no danger of screwing up the next
    request with a bad extension in a .user.ini file.
    Hmm, it looks like cli doesn't have .user.ini support at all.  Does this
    mean we should implement .user.ini for these SAPIs? I'd be in favor.
    Yes, that's on our todos :)

    The idea is to take all the code out of fcgi or fpm and shares it
    across all (relevant) SAPIs.

    Cheers,
  • Hannes Magnusson at Nov 11, 2011 at 11:54 pm

    On Fri, Nov 11, 2011 at 22:43, Edward Z. Yang wrote:
    Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011:
    Well, it is simple enough that we don't really need a patch. However,
    generally if you want to submit a patch it needs to be against a current
    svn branch and not an old release. You want to minimize the work people
    will need to do to look at your suggested change. Gotcha.
    The other issue with your patch is that you are enabling this for the
    fpm sapi. I thought we agreed that this should only be in the sapis that
    supported dl() and those are cgi, cli and embed. And .user.ini doesn't
    apply to embed, so it would just be cli and cgi because these are the
    non-persistent cases where there is no danger of screwing up the next
    request with a bad extension in a .user.ini file.
    Hmm, it looks like cli doesn't have .user.ini support at all.  Does this
    mean we should implement .user.ini for these SAPIs? I'd be in favor.
    Hmh.
    Whats the difference between .user.ini and -dextension=?
    I hate it when bucketloads of .ini files are picked up when I run PHP via cli

    -Hannes
  • Edward Z. Yang at Nov 12, 2011 at 6:54 pm

    Excerpts from Hannes Magnusson's message of Fri Nov 11 18:54:27 -0500 2011:
    Hmh.
    Whats the difference between .user.ini and -dextension=?
    I hate it when bucketloads of .ini files are picked up when I run PHP via cli
    The idea would be to make it easy to simulate the same configuration as
    when you run from the web as when you run from the command line, since
    scripts might be sensitive to those parameters.

    Edward
  • Pierre Joye at Nov 12, 2011 at 7:37 pm

    On Sat, Nov 12, 2011 at 7:54 PM, Edward Z. Yang wrote:
    Excerpts from Hannes Magnusson's message of Fri Nov 11 18:54:27 -0500 2011:
    Hmh.
    Whats the difference between .user.ini and -dextension=?
    I hate it when bucketloads of .ini files are picked up when I run PHP via cli
    The idea would be to make it easy to simulate the same configuration as
    when you run from the web as when you run from the command line, since
    scripts might be sensitive to those parameters.
    I'm not sure it makes to have .user.ini support in CLI as you can
    simply do php -c .user.ini and that's it. I was more thinking of doing
    it in web servers related SAPIs only.

    Cheers,

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 8, '11 at 8:23a
activeNov 12, '11 at 7:37p
posts19
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase