# Integrate PECL into PHP - Thread: https://externals.io/message/62036 - Original archive: https://news-web.php.net/php.internals/62036 - Started by Yahav Gindi Bar on 2012-08-04T19:57:49+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #62036 — Yahav Gindi Bar — 2012-08-04T19:57:49+00:00 URL: https://externals.io/message/62036#62036 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: What do you think? --- ## #62037 — Nikita Popov — 2012-08-04T20:03:23+00:00 URL: https://externals.io/message/62036#62037 · In reply to: #62036 > 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 --- ## #62038 — Andrew Faulds — 2012-08-04T20:05:37+00:00 URL: https://externals.io/message/62036#62038 · In reply to: #62037 > > > […] > 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/ --- ## #62039 — Yahav Gindi Bar — 2012-08-04T20:08:19+00:00 URL: https://externals.io/message/62036#62039 · In reply to: #62037 > On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar > wrote: > > […] > put > > […] > right > > […] > > 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...) --- ## #62040 — Ferenc Kovacs — 2012-08-04T20:12:14+00:00 URL: https://externals.io/message/62036#62040 · In reply to: #62036 > 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: > > > $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 --- ## #62041 — Ferenc Kovacs — 2012-08-04T20:19:30+00:00 URL: https://externals.io/message/62036#62041 · In reply to: #62038 > > > > […] > 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 --- ## #62042 — Stas Malyshev — 2012-08-04T20:37:09+00:00 URL: https://externals.io/message/62036#62042 · In reply to: #62036 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 --- ## #62043 — Yahav Gindi Bar — 2012-08-04T20:50:14+00:00 URL: https://externals.io/message/62036#62043 · In reply to: #62040 > > > On Sat, Aug 4, 2012 at 9:57 PM, Yahav Gindi Bar wrote: > > > […] > > 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 :) --- ## #62044 — Lester Caine — 2012-08-04T21:36:27+00:00 URL: https://externals.io/message/62036#62044 · In reply to: #62043 Yahav Gindi Bar wrote: > > […] > 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 --- ## #62045 — Tom Boutell — 2012-08-05T02:16:29+00:00 URL: https://externals.io/message/62036#62045 · In reply to: #62044 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 (: > Yahav Gindi Bar wrote: > > […] > > > 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 > > > > > -- > > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com