# Load extensions for .user.ini files - Thread: https://externals.io/message/56143 - Original archive: https://news-web.php.net/php.internals/56143 - Started by Edward Z. Yang on 2011-11-08T08:23:14+00:00 - Messages: 19 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #56143 — Edward Z. Yang — 2011-11-08T08:23:14+00:00 URL: https://externals.io/message/56143#56143 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 --- ## #56144 — Rasmus Lerdorf — 2011-11-08T08:40:17+00:00 URL: https://externals.io/message/56143#56144 · In reply to: #56143 > 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 --- ## #56146 — Edward Z. Yang — 2011-11-08T08:46:28+00:00 URL: https://externals.io/message/56143#56146 · In reply to: #56144 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 --- ## #56147 — Rasmus Lerdorf — 2011-11-08T08:54:56+00:00 URL: https://externals.io/message/56143#56147 · In reply to: #56146 > Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: > > […] > > 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 --- ## #56149 — Edward Z. Yang — 2011-11-08T09:03:12+00:00 URL: https://externals.io/message/56143#56149 · In reply to: #56147 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 --- ## #56150 — Yasuo Ohgaki — 2011-11-08T09:26:37+00:00 URL: https://externals.io/message/56143#56150 · In reply to: #56149 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 > Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:54:56 -0500 2011: > > […] > > OK, can do! > > Cheers, > Edward --- ## #56268 — Edward Z. Yang — 2011-11-11T03:14:59+00:00 URL: https://externals.io/message/56143#56268 · In reply to: #56144 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: > > > […] > > 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 --- ## #56282 — Christopher Jones — 2011-11-11T19:28:30+00:00 URL: https://externals.io/message/56143#56282 · In reply to: #56268 > 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/ --- ## #56283 — Edward Z. Yang — 2011-11-11T19:32:52+00:00 URL: https://externals.io/message/56143#56283 · In reply to: #56282 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: > > > > > […] > > What about logging a bug for that specific change so it doesn't get lost, and so > it can be tracked? > > Chris --- ## #56284 — Will Fitch — 2011-11-11T19:36:02+00:00 URL: https://externals.io/message/56143#56284 · In reply to: #56283 You should always tie a patch to a bug/feature request. Need to know/remember why the patch was applied in the first place. > 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: > > […] --- ## #56286 — Rasmus Lerdorf — 2011-11-11T19:38:13+00:00 URL: https://externals.io/message/56143#56286 · In reply to: #56268 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. > 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: > > […] --- ## #56287 — Edward Z. Yang — 2011-11-11T19:42:11+00:00 URL: https://externals.io/message/56143#56287 · In reply to: #56286 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. > > > > […] --- ## #56289 — Rasmus Lerdorf — 2011-11-11T20:45:27+00:00 URL: https://externals.io/message/56143#56289 · In reply to: #56287 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 > 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: > > […] --- ## #56291 — Pierre Joye — 2011-11-11T21:42:11+00:00 URL: https://externals.io/message/56143#56291 · In reply to: #56289 hi, > 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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #56292 — Edward Z. Yang — 2011-11-11T21:43:07+00:00 URL: https://externals.io/message/56143#56292 · In reply to: #56289 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 > > > > […] --- ## #56293 — Pierre Joye — 2011-11-11T21:44:31+00:00 URL: https://externals.io/message/56143#56293 · In reply to: #56292 > > […] > > 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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #56294 — Hannes Magnusson — 2011-11-11T23:54:27+00:00 URL: https://externals.io/message/56143#56294 · In reply to: #56292 > Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011: > > […] > > Gotcha. > > > […] > > 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 --- ## #56302 — Edward Z. Yang — 2011-11-12T18:54:13+00:00 URL: https://externals.io/message/56143#56302 · In reply to: #56294 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 --- ## #56303 — Pierre Joye — 2011-11-12T19:37:51+00:00 URL: https://externals.io/message/56143#56303 · In reply to: #56302 > Excerpts from Hannes Magnusson's message of Fri Nov 11 18:54:27 -0500 2011: > > […] > > 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, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org