I don't think the security problem is fixable.  We have no way to prevent the contents behind a cache entry from changing which is the root of the security problem.  And I don't see the point in open_basedir if you remove the security aspect.  The less secure toggle is to simply turn off open_basedir.  An open_basedir feature that doesn't actually guarantee that users can't open files outside of the specified base directory isn't useful.

Is the cache issue related only when the PHP process is resused for multiple requests with different open_basedir values?

If yes, an extra switch makes 100% sense. The security is 100% kept and realpath cache will be available which makes up too 10x the performace on Windows with file heavy scripts.

@michael: It applies to one request as well as it does multiple requests. One script could, during its lifetime, create and resolve a symlink to a path within open_basedir, then redirect that symlink to a path outside it.

In the interests of having one fewer open tickets regarding open_basedir performance, and since #52312 is still open, I'm going to wontfix this per @rasmus's comment.

> One script could, during its lifetime, create and 
> resolve a symlink to a path within open_basedir, 
> then redirect that symlink to a path outside it

i wonder how it will do that with disable_functions="symlink" which is global and known at startup and with all exec&freinds also in disbale_functions

and if you don't want to implement that check give sensile people which know their environment a ini-option instead disable the realpath cache *hardcoded* based on another ini-option with no chance to say "dear php runtime: look i disabled the race-condition with symlinks and hence the cache is fine, use it"

or fix symlink() to now allow "then redirect that symlink to a path outside it" which would close the issue where it happens instead work around it

https://github.com/Whissi/realpath_turbo

why such a soltion can not be integrated as option in php core?