Integrate PECL into PHP

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/

On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar g.b.yahav@gmail.com
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 g.b.yahav@gmail.comwrote:

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 :)