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

From: Date: Fri, 22 Feb 2013 23:26:14 +0000
Subject: Bug #52312 [Ana]: PHP safe_mode/open_basedir - lstat performance problem
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-177338@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
 Updated by:         rasmus@php.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:

There is no such thing as a "miniscule race" when it comes to computers. Either 
there is a race condition or there isn't. In this case there is. So if we remove 
this check open_basedir will be much less secure. Something along the lines of 
Marcin's idea of separate caches might be feasible, but this is not a small 
change.


Previous Comments:
------------------------------------------------------------------------
[2013-02-22 23:17:59] Terry at ellisons dot org dot uk

This bug is extant in 5.3 and 5.4 (up to 5.4.9).  The flaw is the logic in
main/main.c:php_module_startup():

	/* Disable realpath cache if safe_mode or open_basedir are set */
	if (PG(safe_mode) || (PG(open_basedir) && *PG(open_basedir))) {
		CWDG(realpath_cache_size_limit) = 0;
	}

Similar logic validly exists in code such as suEXEC and suPHP to prevent a race condition allowing
and unscrupulous script author to execute a script in another UID in certain circumstances.  This
simply doesn't apply in this case.  Which technically a similar race could allow a script
author to break the basedir contain with miniscule probability by exploiting such a race, the
performance impacts are significant, for no material increase in security strength.  Get rid of this
rule or at least split open_basedir into two separate directives open_basedir_paranoid which
disables the cache as above and open_basedir which does the rational checks and doesn't disable
the cache.

This has been lying around for nearly 3 years.  How can we progress this?

------------------------------------------------------------------------
[2012-07-31 20:00:48] marcin at 6irc dot net

How about having concurrent cache tables for each basedir setting? For instance, when open_basedir
is set to '/home/teh1234;/tmp', then the lstat populates only cache table "0",
realpath_cache_* also uses exclusively this cache, and when open_basedir is set to
'/home/klaczy;/tmp' then it populates and uses only cache table "1"? Are there
any security considerations that I don't notice here?

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

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


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