Preston L. Bannister wrote: > From: Andi Gutmans [mailto:[EMAIL PROTECTED]] > >>At 14:44 02/05/2002 +0300, Zeev Suraski wrote: >> >>>At 14:00 02/05/2002, [EMAIL PROTECTED] wrote: >>> >>>>On Thu, 2 May 2002, Zeev Suraski wrote: >>>> >>>> >>>>>At 13:36 02/05/2002, [EMAIL PROTECTED] wrote: >>>>> >>>>>>Some hosters use this feature to have different settigns for different >>>>>>customers... >>>>> >>>>>Do you know this for a fact, or is this an estimate? >>>> >>>>This is a fact, some hoster here in .nl uses it. >>> >>>Ok then, perhaps we should have an .ini setting for it? :) >>> >>>The only two options I see, in that case are: >>> >>>- Add the binary path to the 3 existing lookup places >>>- Add a configuration option that would determine whether CWD would be >>>used, or the binary path would be used. >>> >>>I lean towards option #2 myself... >>> >> >>How about if we don't have a php.in in CWD we fall back to where php.exe is >>located? > > > On second thought we *can* have both backwards compatibility AND > a default PHP installation that is more secure. > > The approach is simple: > > Load php.ini from PHP_CONFIG_FILE_PATH (unix) or the same directory > as php.exe (Win32). Do *not* search CWD. > > Add an "include" directive to the INI file. Looking at the PHP > implementation it looks like this could be a psuedo-setting with an > on_modify function that loads as an INI file using the value as a > file name. So sites that *want* to load from CWD would add: > > [PHP] > include_ini = ./php.ini > > So sites that want to be less secure have make the above entry once > in the site's global php.ini. It is a good thing to require action > and thought on the part of the site to become less secure :). >
Interesting idea. It doesn't have to be less secure at all. treat it just like .htaccess config parameters. Only certain ini settings can be override the global ini settings. Shane -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
