Edit report at http://bugs.php.net/bug.php?id=52312&edit=1
ID: 52312
Comment by: cedric at yterium 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:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2010-07-14 15:43:52] v dot damore at gmail dot com
changed summery in order to provide a better description
------------------------------------------------------------------------
[2010-07-13 21:49:55] v dot damore at gmail dot com
Please pay attention correct URL for debugging info is
http://damore.xoom.it/apache-2.2_php-5.3.2_break-lstat.txt
------------------------------------------------------------------------
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=52312
--
Edit this bug report at http://bugs.php.net/bug.php?id=52312&edit=1
