Bug #52312 [Com]: PHP safe_mode/open_basedir - lstat performance problem

From: Date: Tue, 05 Apr 2011 16:27:19 +0000
Subject: Bug #52312 [Com]: PHP safe_mode/open_basedir - lstat performance problem
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-159965@lists.php.net to get a copy of this message 
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] rasmus@php.net

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

Thread (64 messages)

« previous php.bugs (#159965) next »