|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73921 disable_functions should result in fatal error
Submitted: 2017-01-12 13:10 UTC Modified: 2017-01-13 15:44 UTC
From: spam2 at rhsoft dot net Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: 7.1.0 OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2017-01-12 13:10 UTC] spam2 at rhsoft dot net
PHP Warning:  popen() has been disabled for security reasons

sorry, but that is nonsense because from the view of the script it make sno difference if a function can't be called becaus ea typo or because it is disabled and so completly legit code for optional features don't work

BUT you can't try-catch warnings

 private function syslog(string $message)
  global $cms_syslog;
  /** Je nach Serverkonfiguration nicht vorhanden */
   /** Usernamen hinzufuegen wenn angemeldet */
   if(!empty($_SESSION[CMS_HOST_HASH . '_auth_uname']))
    $message .= " ({$_SESSION[CMS_HOST_HASH . '_auth_uname']})";
   /** Sonderzeichen filtern */
   $message = strip_tags($this->escape_logitem($message));
   /** Kommando mittels "popen" ausfuehren und Rueckgabe in Variable schreiben */
   if($fp = popen($cms_syslog . ' ' . escapeshellarg($message) , 'r'))
    return true;
    return false;
  catch(Error $e)
   return false;


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-01-13 15:14 UTC]
-Status: Open +Status: Suspended
 [2017-01-13 15:14 UTC]
Disabling a function isn't the same as undefining it (or never
have it being defined, for that matter), as can be seen from
get_defined_functions() which also returns disabled functions (by
default). Therefore I don't think this qualifies as a bug, but
is rather a feature request.

However, changing the behavior could cause massive BC break, so
this would appear to require the RFC process[1]. Thus I'm
suspending this ticket, until someone comes up with an RFC.

BTW: the example you're presenting isn't a particular good one, as
it would return FALSE regardless of whether disabling popen()
would throw an exception or not.

> BUT you can't try-catch warnings

That's not necessarily correct, see

[1] <>
 [2017-01-13 15:35 UTC] spam2 at rhsoft dot net
> BUT you can't try-catch warnings
That's not necessarily correct

surely, just try it out, this has changed in PHP7, the code below works perfectly when you don't load pecl-apcu and is much cheaper than function_exists() in case normally the extension is expected to be there and have it not loaded is really the exception

i can't see the BC break at all - when someone is calling a function he expects it to be called and on most production servers warnings are nt displayed so he even has no chance to realize why something acts unexpected, with a exception/error it's clear 

frnakly the whole disable_functions() stuff should be reworked so that it also works PER_DIR and not only global (suhosin in the past had a similar feature and i didn't see the pretended performance impact)

     $cache_entry = apcu_fetch($template_key);
     if($cache_entry !== false)
      return $cache_entry;
    catch(Error $e){}
 [2017-01-13 15:44 UTC] spam2 at rhsoft dot net
and when you mean i should create a own error-handler than this would be just pervert when the whole intention of try-catch is to get rid of the expensive function_exists() call which was there in the past

and yes a few function_exists() have a visible cost point in xdebug if you know how to develop really fast systems - no idea hwat function_exists does, but feels like in_array() iterating over the complete list
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Oct 03 02:01:24 2023 UTC