Edit report at https://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Patch added by: f...@php.net
Reported by: mplomer at gmx dot de
Summary: Implement "ondemand" process-manager (to allow zero
children)
Status: Analyzed
Type: Feature/Change Request
Package: FPM related
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fpm-ondemand.v7.patch
Revision: 1309907302
URL:
https://bugs.php.net/patch-display.php?bug=52569&patch=fpm-ondemand.v7.patch&revision=1309907302
Previous Comments:
------------------------------------------------------------------------
[2011-06-11 10:38:18] mplomer at gmx dot de
Unfortunately not, as libevent was removed from FPM in PHP 5.3.4, the patch has
to be ported to the new simple mini event library. If you are interested to do
the port and you are familar with C you are welcome, and I can give you a quick
starting point.
------------------------------------------------------------------------
[2011-06-11 10:22:33] denoc at gmx dot de
I tried to patch php5-5.3.5 with the last offered patch, but it did not work.
Does a patch against the current version exist?
Thanks
------------------------------------------------------------------------
[2010-11-12 02:30:36] luca at fantacast dot it
Just to be clear, I'm not advocating this solution, just contemplating the
implications.
Hand built disable_functions by sysadmins is not realistic and centralized
maintenance in FPM code (if at all possible) would still require work and be
prone to error.
Running as root is very bad security wise and makes almost every other security
check useless in case of a bug.
------------------------------------------------------------------------
[2010-11-12 01:53:01] f...@php.net
> However this could be easily prevented by using disable_functions
> to prevent these and other potentially harmful functions from
> being called (system, exec, etc) which could be used to achieve
> the same goal and are not desirable in a shared hosting environment anyway.
- it's very complex to do.
- you have no guarantee that nothing will be forgotten (until a security hole
is found)
- you have to maintain this security layer over the time, adding new functions,
...
- If the sysadm have to list the functions to be forgotten, it will forget some
(by following a buggy how-to -- which are all over the
Internet btw)
> Obviously this wouldn't protect against PHP bugs
> allowing arbitrary code execution, so it only
> mitigates the potential risk.
I'm sorry, but it's not an option to me. There security checks at kernel level
which must not be gotten arround by code running from userland
(PHP core).
------------------------------------------------------------------------
[2010-11-12 01:28:55] luca at fantacast dot it
Just a thought on the dynamic setuid/setgid/chroot via fastcgi variables
exclusion because of security concerns.
In the group discussion you pointed out how this opens up the possibility for
an attacker to call posix_setuid/posix_setgid in PHP code to get root
privileges.
However this could be easily prevented by using disable_functions to prevent
these and other potentially harmful functions from being called (system, exec,
etc) which could be used to achieve the same goal and are not desirable in a
shared hosting environment anyway.
I guess this and other protections could be even enforced automatically by PHP
FPM if dynamic setuid/setgid/chroot via fastcgi variables is requested.
Obviously this wouldn't protect against PHP bugs allowing arbitrary code
execution, so it only mitigates the potential risk.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52569
--
Edit this bug report at https://bugs.php.net/bug.php?id=52569&edit=1
