On Wed, 2004-02-11 at 17:42, Stanislav Malyshev wrote:
> SC>> 2. php's dl implementation is broken by design, it should never unload a
> SC>> dl. not only is that a performance issue, but it requires all kinds of
> SC>> code to verify that the dl CAN be unloaded properly, thus the problem
> SC>> with dl in php.
>
> Heya... If you don't unload dl(), all arguments about ISPs that use dl()
> for managing extension access go to the drain. So why would you need dl()
> then, again?
>
> SC>> 3. there are no security implications of allowing dl to work only on a
> SC>> single specific directory (or sub directories of that)
>
> So argument about "allowing users load extensions when there's no access
> to php.ini" is dead too - if they don't have php.ini, why would they have
> access to that golden directory - which is much more serious security
> risk?
>
> So, remind me, why do you need dl() at all?
Convenience, modularity, ease of administration (or lack thereof for
people using shared hosting environments). With dl() you can install an
extension from PECL and use it immediately even in a shared hosting
environment. If I hosted by stuff in such an environment, I would have
felt it as a real PITA to not be able to maintain by own PECL/PEAR
extensions.
On top of that, many of PHP's extensions have additional options where
you can enable or disable features, and having the colo admin change an
extension could take even longer than having it installed in the first
place.
Without dl(), using PECL will be limited to those in control of their
php.ini. Technically, there is really no reason for such a limitation.
As Shane says, it is the current design of dl() that's broken. Let's
try coming up with a new design and reimplement it for 5.x instead of
making it Someone Elses Problem.
One idea could be to "ghost" extensions in requests where they should
not be available. Instead of unloading the extension, its
functions/methods could be tagged as "disabled" (for example using a bit
in zend_function_entry.flags). The same trick could work for constants
and classes too.
Pros and cons for ghosting as I see it:
* Pro: persistent resources would work
* Con: extra check (although just one or two assembly
instructions) per function/method call and class/constant lookup
* Con: some more complexity in the engine with these checks
* Pro: would keep current dl() semantics
- Stig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
