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 :). -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
