Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85993
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rochette.cc designates 195.154.14.121 as permitted sender)
Message-ID: <553F918E.90507@rochette.cc>
Date: Tue, 28 Apr 2015 15:56:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <5538E1EE.6010201@rochette.cc> <CA+kxMuR7Bj1SPgk-j49KDGDaP=c=gPfTGAEG2Y2+MK+qcfgB9w@mail.gmail.com> <55395102.1080109@rochette.cc>
In-Reply-To: <55395102.1080109@rochette.cc>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] clear_env default in php-fpm
From: mathieu@rochette.cc (Mathieu Rochette)

fwiw, the default has just been changed on the "official" php docker 
image : https://github.com/docker-library/php/pull/93

I still think it should be the default so that it would just work for 
any heroku like hosting or user made php docker containers

knowing that it's the default behavior with apache mod_php, anyone can 
think about security issues that could cause ?

On 04/23/2015 10:07 PM, Mathieu Rochette wrote:
>
>
> On 04/23/2015 05:11 PM, Dan Ackroyd wrote:
>> On 23 April 2015 at 12:13, Mathieu Rochette <mathieu@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