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:
> Caching open_basedir stats is insecure
not really because the permissions are not changed the whole day
Previous Comments:
------------------------------------------------------------------------
[2011-07-03 21:21:21] [email protected]
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.
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
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
