On 04/23/2015 05:11 PM, Dan Ackroyd wrote:
On 23 April 2015 at 12:13, Mathieu Rochette <math...@rochette.cc> wrote:
I didn't find much information about this change (even finding about
|clear_env| is not that easy when search for "php fpm env var") so I don't
know if there is others reason than BC.
It looks like it wasn't discussed that much. The PR has a brief conversation:
https://github.com/php/php-src/pull/598
What do you think about changing the default to
|clear_env = no| ?
For 'Container like' hosting where the application being deployed is
owned by the company doing the deploying, and all the configuration is
done automatically and no humans ever touch the machine, having
'clear_env' default to 'no' would make sense.
For, shared hosting and other places where the application being
deployed might not be owned by the same people that control the
server, having 'clear_env' default to 'no' sounds like a security
problem, as it would allow the potential for people to modify the env
settings, which they can't currently do.
What do you mean? As I understand it, clear_env = no, would give users
read access to env variables, not the ability to modify it. am I wrong?
Wouldn't it make more sense just to ask Heroku (or whichever container
provider someone is using) to change the setting in the version of PHP
that they provide. For the general release of PHP, unless someone can
demonstrate how it wouldn't be a security problem, continuing to
default to the current secure setting sounds sensible to me.
I'm not a security expert so I don't know how it could be proven. the
best argument I have is that apache php mod does not AFAIK clears env
and everything seems fine
cheers
Dan
thank you for your reply,
--
Mathieu Rochette
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
