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

From: Date: Thu, 02 Jun 2011 13:01:13 +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-161131@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:         aargoth at boo dot pl
 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:

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/


Previous Comments:
------------------------------------------------------------------------
[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] 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

------------------------------------------------------------------------


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 (#161131) next »