Anton Aylward wrote:
I look at that
<?php $fp=fopen("/var/www/metacafe/test","r"); fclose($fp); ?>
When running with strace -e lstat I see this: lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 lstat("/var/www/metacafe", {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
lstat("/var/www/metacafe/test", 0x7fbfff9b10) = -1 ENOENT (No such file or directory)
and I think its doing
I want to get to "/var/www/metacafe/test". Can I access "/var"?
As it is realpath() doing the calling, I think it's about determining if it's a symlink or not.
This doesn’t explain why it scans so many files, though.
I see two reasons - a modular design which causes many include()s, and using "open_basedir" which disables caching of realpath() results. I could probably provide some real numbers for you tomorrow, but I'm now more interested to see a) how much removing open_basedir will improve the situation, and b) what the security implications of that might be. Fixing processwire and/or the php interpreter are not on my list of priorities :-)
Quite apart from the caching that PHP may or may not be doing between HTTP invocations (probably not, this is a connectionless protocol remember) there should be inode and pathname caching done by the kernel.
Yeah, that is an interesting point. -- Per Jessen, Zürich (17.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org