On Thu, 2002-05-02 at 19:07, 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 :).
Edin and I were discussing ini files on IRC last night and the same idea came up. With the exact same syntax too, actually. This is divine proof that the include_ini is good and must be implemented. :-) Seriously, being able to include other ini files is a great feature, especially for hosters who will then be able to set up site-wide config files that are included from per-vhost config files, etc. You can have your cake and eat it too. - Stig -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
