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

From: Date: Fri, 13 Jul 2012 22:05:48 +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-171932@lists.php.net to get a copy of this message 
Edit report at https://bugs.php.net/bug.php?id=52312&edit=1

 ID:                 52312
 Comment by:         spam2 at rhsoft dot net
 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:

why the hell is a extern extension need to disable this "security feature" nobody needs
who dsiables symlink() at all? this is only a bad joke in my opinion!


Previous Comments:
------------------------------------------------------------------------
[2011-08-16 18:52:34] spam2 at rhsoft dot net

> Caching open_basedir stats is insecure

not really because the permissions are not changed the whole day

------------------------------------------------------------------------
[2011-07-03 21:21:21] rasmus@php.net

I really don't see a middle ground here. You are either secure or you aren't. Caching
open_basedir stats is insecure and the whole point of open_basedir in a shared hosting setup is to
secure these file accesses. If you don't care about security, turn it off and live with the
security issue, or better yet, change your shared hosting setup to use VMs or other lower-level
strategies that keep users separated from each other.

------------------------------------------------------------------------
[2011-07-03 20:24:57] css at morefoo dot com

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.

------------------------------------------------------------------------
[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.

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


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

Thread (64 messages)

« previous php.bugs (#171932) next »