[PHP-DEV] Integrate PECL into PHP

Hi,

After the last discussion I've started about runkit which some of you
suggest to keep it in PECL - I thought about the extensions "problem" in
PHP and wish to ask for your opinion.

Many developers use shared hosting as PHP env which not allows them to
install new extensions in PHP.
In order to give users ability to use extensions, I'm suggesting that we'll
add some PECL related methods to the PHP core (with ini option to disable
it, or create a PECL package) that allows users to install PECL packages
through PHP code even in shared hosting env.

We had dl() until it was deprecated, and even when we got it I guess that
administrators disabled the dl() method because of security reasons.
However, PECL got limited extensions which, as long as I know, does not put
the server into security risks (maybe I've said something VERY STUPID right
now, so excuse me...)

Idea example:

<?php

$extensionsList = pecl_get_available_extensions();
if (! pecl_extension_installed('...') ) {
pecl_install_extension('...');
}

?>

What do you think?

On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar <[email protected]> wrote:
> We had dl() until it was deprecated, and even when we got it I guess that
> administrators disabled the dl() method because of security reasons.
> However, PECL got limited extensions which, as long as I know, does not put
> the server into security risks (maybe I've said something VERY STUPID right
> now, so excuse me...)

PECL extensions are C code. "C code" is programmer slang for "security risk".

I mean, seriously, extension code can be pretty much everything.
Allowing people to load extensions from userland would go beyond
fatal.

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 04/08/12 21:03, Nikita Popov wrote:
> On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar <[email protected]> wrote:
>> We had dl() until it was deprecated, and even when we got it I guess that
>> administrators disabled the dl() method because of security reasons.
>> However, PECL got limited extensions which, as long as I know, does not put
>> the server into security risks (maybe I've said something VERY STUPID right
>> now, so excuse me...)
> PECL extensions are C code. "C code" is programmer slang for "security risk".
>
> I mean, seriously, extension code can be pretty much everything.
> Allowing people to load extensions from userland would go beyond
> fatal.
>
> Nikita
>
Aren't shared hosting servers pretty well secured, though? If each site
is under a different userid, surely it can't do much damage?

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Aug 4, 2012 at 11:03 PM, Nikita Popov <[email protected]> wrote:

> On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar <[email protected]>
> wrote:
> > We had dl() until it was deprecated, and even when we got it I guess that
> > administrators disabled the dl() method because of security reasons.
> > However, PECL got limited extensions which, as long as I know, does not
> put
> > the server into security risks (maybe I've said something VERY STUPID
> right
> > now, so excuse me...)
>
> PECL extensions are C code. "C code" is programmer slang for "security
> risk".
>
> I mean, seriously, extension code can be pretty much everything.
> Allowing people to load extensions from userland would go beyond
> fatal.
>
> Nikita
>

Because of that I wondered if it's stupid or not... I understand the reason
to disable the ability to install extensions generally, but doesn't the
extensions in PECL got filtered before adding them to the PECL library?
My main idea is to allow only installation of extensions available in PECL
(just a wrapper to the "pecl" tool, because shared hosting users cannot
access it...)

On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar <[email protected]> wrote:

> Hi,
>
> After the last discussion I've started about runkit which some of you
> suggest to keep it in PECL - I thought about the extensions "problem" in
> PHP and wish to ask for your opinion.
>
> Many developers use shared hosting as PHP env which not allows them to
> install new extensions in PHP.
> In order to give users ability to use extensions, I'm suggesting that we'll
> add some PECL related methods to the PHP core (with ini option to disable
> it, or create a PECL package) that allows users to install PECL packages
> through PHP code even in shared hosting env.
>
> We had dl() until it was deprecated, and even when we got it I guess that
> administrators disabled the dl() method because of security reasons.
> However, PECL got limited extensions which, as long as I know, does not put
> the server into security risks (maybe I've said something VERY STUPID right
> now, so excuse me...)
>
> Idea example:
>
> <?php
>
> $extensionsList = pecl_get_available_extensions();
> if (! pecl_extension_installed('...') ) {
> pecl_install_extension('...');
> }
>
> ?>
>
> What do you think?
>

hi

it is more complicated than that.
pecl is two thing, it is an addition/extension of the pear packaging
infrastructure and pecl is the pear channel hosted on http://pecl.php.net/
the pecl client depends on packages like make, autoconf, automake, php-dev,
etc. to be able to install a pecl package as the packages as hosted as
source code and compiled by the installation process.
it is true that there is an approval process for registering a new package
on pecl.php.net but the pecl extensions are maintained separately from the
php core, and their stability and the response to security issues are lower
than the one for php-src.
with your feature request, you are suggesting that php-src should include a
pear/pecl client which should be aware that only the packages from the
official php.net channels are allowed to be installed (else one can install
anything from anywhere), and you would still need to ask your hoster to
install the make, php-dev, etc. packages for this feature to work.
and if we would add this, from that point, any security issue in any pecl
package would be as serious problem as it was in the php-src.
of course the ISPs and the security minded sysadmins would ask for an
option to be able to disable this feature, which in most distribution would
be the default option.
so in the end, the users of the shared hosting providers would still not be
able to install C extensions on their own, but we would introduce a
potential attack vector to the core.
I think that it isn't something that we should pursue.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Sat, Aug 4, 2012 at 10:05 PM, Andrew Faulds <[email protected]> wrote:

> On 04/08/12 21:03, Nikita Popov wrote:
>
>> On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar <[email protected]>
>> wrote:
>>
>>> We had dl() until it was deprecated, and even when we got it I guess that
>>> administrators disabled the dl() method because of security reasons.
>>> However, PECL got limited extensions which, as long as I know, does not
>>> put
>>> the server into security risks (maybe I've said something VERY STUPID
>>> right
>>> now, so excuse me...)
>>>
>> PECL extensions are C code. "C code" is programmer slang for "security
>> risk".
>>
>> I mean, seriously, extension code can be pretty much everything.
>> Allowing people to load extensions from userland would go beyond
>> fatal.
>>
>> Nikita
>>
>> Aren't shared hosting servers pretty well secured, though? If each site
> is under a different userid, surely it can't do much damage?
>
>
from C code any and all php security measure like
open_basedir, allow_url_include, etc. could be bypassed.
of course the preferred way to secure your a multi-user environment is to
do that outside of php (jail/chroot/suexec etc.), but this would be still
an attack vector.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi!

> Many developers use shared hosting as PHP env which not allows them to
> install new extensions in PHP.

You do realize they do it not because they are evil people thriving on
suffering of their clients, but because they need controlled environment
they can maintain? If you need environment you control, buy a VPS
hosting. Shared hosting is cheap for a reason, and trying to cheat
shared hosters by changing PHP both wrong and pointless.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Aug 4, 2012 at 11:12 PM, Ferenc Kovacs <[email protected]> wrote:

>
>
> On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar <[email protected]>wrote:
>
>> Hi,
>>
>> After the last discussion I've started about runkit which some of you
>> suggest to keep it in PECL - I thought about the extensions "problem" in
>> PHP and wish to ask for your opinion.
>>
>> Many developers use shared hosting as PHP env which not allows them to
>> install new extensions in PHP.
>> In order to give users ability to use extensions, I'm suggesting that
>> we'll
>> add some PECL related methods to the PHP core (with ini option to disable
>> it, or create a PECL package) that allows users to install PECL packages
>> through PHP code even in shared hosting env.
>>
>> We had dl() until it was deprecated, and even when we got it I guess that
>> administrators disabled the dl() method because of security reasons.
>> However, PECL got limited extensions which, as long as I know, does not
>> put
>> the server into security risks (maybe I've said something VERY STUPID
>> right
>> now, so excuse me...)
>>
>> Idea example:
>>
>> <?php
>>
>> $extensionsList = pecl_get_available_extensions();
>> if (! pecl_extension_installed('...') ) {
>> pecl_install_extension('...');
>> }
>>
>> ?>
>>
>> What do you think?
>>
>
> hi
>
> it is more complicated than that.
> pecl is two thing, it is an addition/extension of the pear packaging
> infrastructure and pecl is the pear channel hosted on http://pecl.php.net/
> the pecl client depends on packages like make, autoconf, automake,
> php-dev, etc. to be able to install a pecl package as the packages as
> hosted as source code and compiled by the installation process.
> it is true that there is an approval process for registering a new package
> on pecl.php.net but the pecl extensions are maintained separately from
> the php core, and their stability and the response to security issues are
> lower than the one for php-src.
> with your feature request, you are suggesting that php-src should include
> a pear/pecl client which should be aware that only the packages from the
> official php.net channels are allowed to be installed (else one can
> install anything from anywhere), and you would still need to ask your
> hoster to install the make, php-dev, etc. packages for this feature to work.
> and if we would add this, from that point, any security issue in any pecl
> package would be as serious problem as it was in the php-src.
> of course the ISPs and the security minded sysadmins would ask for an
> option to be able to disable this feature, which in most distribution would
> be the default option.
> so in the end, the users of the shared hosting providers would still not
> be able to install C extensions on their own, but we would introduce a
> potential attack vector to the core.
> I think that it isn't something that we should pursue.
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>


Yes, I agree with you... but still I wish somehow to give shared hosting
users ability to extend their projects with PECL somehow... any thoughts?


from C code any and all php security measure like
> open_basedir, allow_url_include, etc. could be bypassed.
> of course the preferred way to secure your a multi-user environment is to
> do that outside of php (jail/chroot/suexec etc.), but this would be still
> an attack vector.

Because of that I've suggested only extensions in PECL only which has
approval process...

You do realize they do it not because they are evil people thriving on
> suffering of their clients, but because they need controlled environment
> they can maintain?

I don't think that they're evil (I was one of them long ago, lol) and now I
do use dedicated server for my company sites and VPS for development, which
is different story.

If you need environment you control, buy a VPS
> hosting.

I think there're users that could buy VPS but afraid of maintain the
server.
I wish to find a solution in PHP because it's maintaining free for the
end-user.


> Shared hosting is cheap for a reason, and trying to cheat
> shared hosters by changing PHP both wrong and pointless.

My wish is not to cheat using PHP but to give the shared hosting users
somehow the ability to enjoy from PECL packages without being restricted to
their providers.

Got your point - maybe it's not possible and I'm just trying to keep the
cake and eat it... even this said, if somebody got an implementation idea
or any other way (except from requesting it from the provider) I'd love to
hear it :)

Yahav Gindi Bar wrote:
>> Shared hosting is cheap for a reason, and trying to cheat
>> >shared hosters by changing PHP both wrong and pointless.
> My wish is not to cheat using PHP but to give the shared hosting users
> somehow the ability to enjoy from PECL packages without being restricted to
> their providers.
>
> Got your point - maybe it's not possible and I'm just trying to keep the
> cake and eat it... even this said, if somebody got an implementation idea
> or any other way (except from requesting it from the provider) I'd love to
> hear it:)

On most distributions many of the core facilities are simply a group of enabled
modules. All that is required to use PECL as well is for those module to be
packaged and available in the list of enable-able modules. I don't think that
anything should be done to take that control away from the ISP's that are
providing the service.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

There is already a safe and sensible way to do this in a shared
hosting environment: the host installs pecl packages that everyone
gets, and only after verifying that they don't reduce the security of
the shared environment. Or, yes, just get a vps! Really, it's not
expensive anymore (:

On Sat, Aug 4, 2012 at 5:36 PM, Lester Caine <[email protected]> wrote:
> Yahav Gindi Bar wrote:
>>>
>>> Shared hosting is cheap for a reason, and trying to cheat
>>> >shared hosters by changing PHP both wrong and pointless.
>>
>> My wish is not to cheat using PHP but to give the shared hosting users
>> somehow the ability to enjoy from PECL packages without being restricted
>> to
>> their providers.
>>
>> Got your point - maybe it's not possible and I'm just trying to keep the
>> cake and eat it... even this said, if somebody got an implementation idea
>> or any other way (except from requesting it from the provider) I'd love to
>> hear it:)
>
>
> On most distributions many of the core facilities are simply a group of
> enabled modules. All that is required to use PECL as well is for those
> module to be packaged and available in the list of enable-able modules. I
> don't think that anything should be done to take that control away from the
> ISP's that are providing the service.
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php