It has been INI_ALL for a looong time until somebody decided to set it
to INI_SYSTEM.
Actually it was "--enable-url-fopen" for a loong time until it became
runtime configurable. It was *mistakenly* set to PHP_INI_ALL, but was
supposed to have been PHP_INI_SYSTEM. (In line with prior behavio
Would that not already be possible by calling ini_restore() ?
Well yes... I just mean the thing was INI_ALL not sooo long ago. Maybe
some script have something like this:
ini_set("allow_url_fopen", 0);
... do include stuff ..
ini_set("allow_url_fopen", 1);
such functionality was broken a
On Mon, 27 Jun 2005, Stefan Esser wrote:
> > I think Stefan's idea of allowing the setting to be disabled by the script,
> > but not enabled by it is the best. This way script writers who know which
> > parts of the app/library do not need the functionality can explicitly
> > disable it there.
>
Stefan Esser wrote:
My idea was a little bit different. I would like to allow disabling and
enabling. Of course enabling only if the vhost setting says that it was
enabled in the first place.
Would that not already be possible by calling ini_restore() ?
Ilia
--
PHP Internals - PHP Runtime De
Hi Ilia,
I think Stefan's idea of allowing the setting to be disabled by the
script, but not enabled by it is the best. This way script writers who
know which parts of the app/library do not need the functionality can
explicitly disable it there.
My idea was a little bit different. I would l
On Mon, 27 Jun 2005, Ilia Alshanetsky wrote:
> IMO disable allow_url_fopen by default is a bad idea as it would break
> multitudes of applications that rely on being open URLs via various PHP
> functions like getimagesize(), simplexml_load_file(), etc...
>
> I think Stefan's idea of allowing the
IMO disable allow_url_fopen by default is a bad idea as it would break
multitudes of applications that rely on being open URLs via various PHP
functions like getimagesize(), simplexml_load_file(), etc...
I think Stefan's idea of allowing the setting to be disabled by the
script, but not enable
On Mon, 27 Jun 2005, Rasmus Lerdorf wrote:
> Yikes, when did that happen? I have been out of Internet reach in the
> wilds of Finland for a few days, so I missed a bunch of stuff, but
> making allow_url_fopen an INI_ALL option seems like a fantastically bad
> idea. Admins should be able to contr
At 10:29 27/06/2005, Derick Rethans wrote:
On Mon, 27 Jun 2005, Stefan Esser wrote:
> Without a new ini directive I only see the possibility to build an
emulation
> layer:
>
> Sys: allow_url_fopen = Off -> User: ini_set("allow_url_fopen",1) fails
> Sys: allow_url_fopen = On -> User: ini_set(
At 10:24 27/06/2005, Stefan Esser wrote:
I think most of us can agree following statement
"allow_url_fopen = ON" is dangerous and the feature is not
useful most of the times.
No, allow_url_fopen = ON is not dangerous and it is a very useful feature
when you want to fopen() a remote URL. What y
Derick Rethans wrote:
> On Mon, 27 Jun 2005, Stefan Esser wrote:
>
>
>>From my point of view it would have been better to have another ini directive
>>like allow_url_includes that defaults to off. However under no circumstances
>>allow_url_fopen can be turned back to INI_ALL. An admin has to deci
On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
> > I disagree. With proper filtering, or using non-user-supplied
> > information there is no problem.
>
> I don't have objection to your statement.
> It could be used safely, but there are many applications that
> had serious problems even if application
On Mon, 27 Jun 2005, Stefan Esser wrote:
> From my point of view it would have been better to have another ini directive
> like allow_url_includes that defaults to off. However under no circumstances
> allow_url_fopen can be turned back to INI_ALL. An admin has to decide if he
> allows any kind of
I think most of us can agree following statement
"allow_url_fopen = ON" is dangerous and the feature is not
useful most of the times.
No, allow_url_fopen = ON is not dangerous and it is a very useful
feature when you want to fopen() a remote URL. What you may consider
dangerous is that URLs w
Derick Rethans wrote:
> On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
>
>
>>I think most of us can agree following statement
>>
>>"allow_url_fopen = ON" is dangerous and the feature is not
>>useful most of the times.
>
>
> I disagree. With proper filtering, or using non-user-supplied
> information
On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
> I think most of us can agree following statement
>
> "allow_url_fopen = ON" is dangerous and the feature is not
> useful most of the times.
I disagree. With proper filtering, or using non-user-supplied
information there is no problem.
Derick
--
Deri
On Mon, 27 Jun 2005, Yasuo Ohgaki wrote:
Derick Rethans wrote:
On Sun, 26 Jun 2005, Sara Golemon wrote:
Yes, unregister/restore is PHP5 only. I'd personally be okay with merging
this to 4.4 as the bulk of the support for it is already there internally,
it's just adding a couple PHP_FUNCTION
Derick Rethans wrote:
> On Sun, 26 Jun 2005, Sara Golemon wrote:
>
>
>>Yes, unregister/restore is PHP5 only. I'd personally be okay with merging
>>this to 4.4 as the bulk of the support for it is already there internally,
>>it's just adding a couple PHP_FUNCTION hooks to make it happen. That'
I think most of us can agree following statement
"allow_url_fopen = ON" is dangerous and the feature is not
useful most of the times.
Stefan Esser wrote:
>> It's not stupid to prevent them from being made. But that's not what
>> an admin does. When the admin comes into play, the application is
>>
It's not stupid to prevent them from being made. But that's not what
an admin does. When the admin comes into play, the application is
already "made" and employed. The admin just prevents it from working as the
developer and the qa-team intended.
The admin is deciding what is allowed on his syst
On Sun, Jun 26, 2005 at 06:21:54PM +0100, Matthew Charles Kavanagh wrote:
> It's stupid to prevent stupid applications from being made to do stupid
> things by stupid people?
It's not stupid to prevent them from being made. But that's not what
an admin does. When the admin comes into play, the ap
On Sun, Jun 26, 2005 at 09:02:23AM -0700, Sara Golemon wrote:
[...]
> > allow_url_fopen should not be site wide configuration for security
> > seasons.
> >
> allow_url_fopen is for site administrators to globally stop users from being
> stupid.
stop them from being stupid by breaking their appli
On Sun, 26 Jun 2005, Sara Golemon wrote:
> Yes, unregister/restore is PHP5 only. I'd personally be okay with merging
> this to 4.4 as the bulk of the support for it is already there internally,
> it's just adding a couple PHP_FUNCTION hooks to make it happen. That's up
> to the RM and general
> 1) INI_SYSTEM disables to patch vulnerable application by adding
> ini_set().
> ini_set('allow_url_fopen', 0);
> // some dangerous include/require statement
> ini_set('allow_url_fopen', 1); // reenable if allow_url_fopen is
> required
>
$allowed_wrappers = array('php','file');
foreach(str
24 matches
Mail list logo
