Edit report at https://bugs.php.net/bug.php?id=52312&edit=1
ID: 52312
Comment by: css at morefoo dot com
Reported by: v dot damore at gmail dot com
Summary: PHP safe_mode/open_basedir - lstat performance
problem
Status: Analyzed
Type: Bug
Package: Safe Mode/open_basedir
Operating System: Linux
PHP Version: 5.2.13
Block user comment: N
Private report: N
New Comment:
Hello,
Not much more than a "me too", sorry. Is there any plan in the works to make
php
both safe in a mass hosting setup as well as not take a big performance hit
when
running webapps with a large number of "require" and "include" functions? I'm
running php 5.3.6 and still seeing a huge amount of cpu time spent in "system"
on
common web apps like Joomla, Drupal and C5. Not seeing a clear solution that
works well on a shared hosting setup.
Previous Comments:
------------------------------------------------------------------------
[2011-06-02 15:01:13] aargoth at boo dot pl
You can simply use this PHP extension to bypass default security checks
mentioned in comments above.
http://php.webtutor.pl/en/2011/06/02/running-php-on-nfs-huge-performance-problems-and-one-simple-solution/
------------------------------------------------------------------------
[2011-04-05 18:27:16] cedric at yterium dot com
As a matter of fact, same performance problem occurs with PHP Version 5.3.3 on
Debian Squeeze.
On our test plateform (with an SSD disk) a small bench show that the penalties
of using open_basedir is more than small on real case application.
Base configuration :
ab -n200 -c20 http://benchb.xxx.yy/
Requests per second: 266.45 [#/sec] (mean)
After open_basedir activation :
Requests per second: 82.95 [#/sec] (mean)
Recompiling with --disable-phar doesn't reduce the performance gap.
Recompiling after patching main/main.c with comment on both occurences of :
//CWDG(realpath_cache_size_limit) = 0;
allows to reach an acceptable performance :
Requests per second: 178.27 [#/sec] (mean)
By increasing the realpath cache, we can at last reach a smaller penalty :
Requests per second: 220.69 [#/sec] (mean)
Our tries tu use open_basedir on NFS leads us to more dramatic situation.
Can we expect a fix for a better situation in further PHP versions ?
Maybe this realpath cache de-activation could be a default setting in case of
open_basedir with the ability of re-activating without need of recompiling.
I know this can be a security hole, but maybe it's better to give an
intermediate choice between on/off.
I'm affraid that in the current situation, activating open_basedir is not
really an acceptable choice due to the performance struggling, and I think
that's worse for security.
------------------------------------------------------------------------
[2010-07-23 13:26:00] v dot damore at gmail dot com
Hello,
I have recompiled php commenting both in main/main.c:
/*
if (PG(safe_mode) || (PG(open_basedir) && *PG(open_basedir))) {
CWDG(realpath_cache_size_limit) = 0;
}
*/
I have defined into TSRM/tsrm_virtual_cwd.c
#define realpath(x,y) strcpy(y,x)
and I have disabled PHP function symlink.
Now I finally not have performance problems, but I suppose I still can have
security problem.
Can you help me in order to understand if there is a better solution?
------------------------------------------------------------------------
[2010-07-14 16:25:28] v dot damore at gmail dot com
I want make it clear first that: in submitted test we can see only 4 directory
scan, I my production environment I have seen up to 8 directory scan for php
file.
If we disable PHAR I suppose only first full scan path will be removed.
So other 3 full scan path remain there, probably we need to change
php_check_specific_open_basedir in order to really try to remove inefficiencies.
------------------------------------------------------------------------
[2010-07-14 15:58:22] [email protected]
Yup, there are clearly some inefficiencies here. We are relying too much on
the
realpath_cache being enabled. You can eliminate the phar one by eliminating
phar
for now. Recompile with --disable-phar until we get this cleaned up.
------------------------------------------------------------------------
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=52312
--
Edit this bug report at https://bugs.php.net/bug.php?id=52312&edit=1
