This code is executed at the time when the php.ini file is parsed. So this happens the first time the php engine starts (i.e., for Apache, at the time of apache parent startup). The additional_ini capability has the same security issues that the php.ini file itself has. So I'm not sure there are any new security concerns that surface because of this patch.
You mention the ini_set/ini_get functions. There's also the "parse_ini_file" extension function (http://www.php.net/manual/en/function.parse-ini-file.php) which allows you to parse your own ini files at runtime. I think this function along with ini_set are sufficient to handle run time ini files. dave -----Original Message----- From: James Moore [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 10:32 AM To: 'Php-Dev@lists. php. net' Cc: 'David Viner'; 'Rasmus Lerdorf'; 'Edin Kadribasic' Subject: RE: [PHP-DEV] [PATCH] include statement in php.ini file In general I agree with this proposal but I have some concerns, as I am not familiar with the ini code these may be unfounded, introducing it may well 1) Introduce Security Concerns depending on the time the ini file is loaded (IF I have safe_mode = on then you include an ini file with safe_mode = off what happens) 2) If people use this with out understanding when the ini file is loaded. Php.ini is loaded before script execution/compilation this ini file would probably be loaded at compile or runtime so settings like sort_tags = on and register_globals = on would not make sense. Therefore, if appropriate (IE my concerns are well founded) I suggest we add two new ini directives to the php.ini file (allow.runtime.ini.files (Which defaults to off due to the fact that someone may upgrade to Php 4.3.x or whenever this appears and not update their php.ini file leaving their system vurlnerable to safe_mode among others being turned off at runtime). At the same time we add the directive disallow.directive.overwrite which is given a list of ini directives which cannot be overwritten by runtime loading). I realize there is ini_set and ini_get at the moment and these issues may have already been dealt with, as I said I do not know quite what the situation is with the ini code as I am unfamilar with it but I feel that these things need to be thought about before the patch makes it into a release (or at least rubished enough so that Im sure these concerns are unfounded :). Cheers, - James > > > I'm not very concerned either way on the .ini extension > > restriction. > > > Let's go ahead and commit this with the "include" to > > "additional_ini" name > > > change. Perhaps the commit will stir up more feedback since there > > has > > > been so little. > > > > Some feedback: > > > > +1 for additional_ini=/path/to/new/additional.ini > > -1 for including whole directories, since I think it has to great a > > WTF factor. > > Without scanning a directory, you would have to automatically > edit and insert directives into files in order to add an > extension automatically. It is so much easier just to drop a > single ext.ini file in a dedicated ini dir and have it be > read. Scanning a file and trying to figure out where to add > stuff and making sure it isn't already there is a real PITA. > Like the silly LoadModule stuff that apxs does. You often > end up with multiple LoadModule lines for the same module. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
