Heh disable_functions and open_basedir is bad example. It's not an apache part - it's PHP, so forget about it - <it's a feature of PHP>. enable_functions is a very bad idea - the list of allowed ones would be too large for any business, development or user needs. That's why administrators (I do) read changelogs before upgrading software, and why they check all the functions documented and all the details regarding what these functions do, this is PHP feature, not httpd feature or httpd bug. The question is why PHP processes, forks etc running under apache/cgi/etc are allowed to do anything what apache can do. This is the issue right? If PHP has security a bug, which allows to bypass these php.ini-related security/sandboxing settings, it means we should sacrifice security needs and trust PHP only? I need them both, where possible. We can't even control and isolate subprocesses with selinux, because for cgroups/selinux they share same group and contexts. BTW, one reminded me in here - itk mpm has workarounds for this problem. http://mitka.us/articles/mpm-itk/ It's definitely not a bug, it's an architecture, which must be redesigned sooner or later. On Mon, Aug 12, 2013 at 9:28 PM, Coderaptor <coderaptor@xxxxxxxxx> wrote: > > disable_functions Best regards, George Machitidze
