Edit report at http://bugs.php.net/bug.php?id=52569&edit=1
ID: 52569
Comment by: denoc at gmx dot de
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:
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
Previous Comments:
------------------------------------------------------------------------
[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] [email protected]
> 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.
------------------------------------------------------------------------
[2010-09-25 18:26:58] mplomer at gmx dot de
Released patch v6 - Updated patch to be compatible with current PHP_5_3 branch
(rev 303365)
There are no functional changes against v5
Merged (removed) parts which have already been committed:
- rev 301886: only one process (for all pools) could be killed by the 'dynamic'
process manager
- rev 301912: Changed listen.backlog in the FPM configuration file to default
to 128 instead of -1
- rev 301913: Add libevent version to the startup debug log in FPM
- rev 301925: add 'max children reached' to the FPM status page
Changes:
- Undo change in config.m4 which has IMHO nothing to do with this patch
- Merged listen.backlog part in php-fpm.conf.in from trunk (trunk and
5.3-branch is currently out of sync here!)
- (small code beautify)
------------------------------------------------------------------------
[2010-09-13 06:27:20] [email protected]
You should "make clean" before recompiling with v5 patch.
The v5 patch does not apply on 5.3.3, it applies on the svn PHP5_3_3 branch.
++ Jerome
------------------------------------------------------------------------
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
http://bugs.php.net/bug.php?id=52569
--
Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1
