RE: [PHP-DEV] config.w32.h...registry configuration
| From: | Stig S. Bakken | Date: | Fri, 03 May 2002 04:51:50 +0000 |
| Subject: | RE: [PHP-DEV] config.w32.h...registry configuration | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-83632@lists.php.net to get a copy of this message | ||
On Thu, 2002-05-02 at 19:07, Preston L. Bannister wrote:
> From: Andi Gutmans [mailto:andi@zend.com]
> >
> > At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
> > >At 14:00 02/05/2002, derick@php.net wrote:
> > >>On Thu, 2 May 2002, Zeev Suraski wrote:
> > >>
> > >> > At 13:36 02/05/2002, derick@php.net 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