I have just written a hack/patch to APC that changes the behavior so that it mmaps the memory *after *request initialization, when the first request is handled by the thread. It will then make a mmap without closing the file handle so that it can be opened again by threads later on. I have tested it (however not stress tested it) and it appears to be working fine. There where tons of issues doing this which I wrote workarounds for. The biggest nuisance was the fact that the memory contains a bunch of addresses and so the mmap had to be mapped to the same memory address requiring preallocation and page boundary alignment etc.
One thing I didn't solve however... it appears the file is automatically being flushed when MAP_ANONYMOUS is disabled.. so basically the cache is constantly written to disk, plus the fact that the file is the size of the maximum memory available by APC... 32M by default. This uses up valuable resources and there's no way to disable this... And it makes the patch kinda pointless as the whole point of APC is to make PHP use *less* memory. Hannes On 15 January 2011 19:13, Hannes Landeholm <[email protected]> wrote: > Unfortunately, no. Just checked, and the behavior of xcache is exactly the > same as with APC. > > I set xcache.mmap_path and looking at the strace output of apache I saw > that it opened this file in the main process once and long before the > peruser processor was chrooted. And since I didn't find the opened file I > can only assume that xcache deletes it's mmap file too. > > Hannes > > > On 14 January 2011 21:23, Leen Besselink <[email protected]> wrote: > >> On 01/14/2011 08:23 PM, Hannes Landeholm wrote: >> > Yes, you could use prefixing to prevent name collision in between >> > environments but that doesn't address the security issue. As long as >> > environments share memory with APC there are no way to prevent cache >> > stealing. The sharing memory part is the root of the problem. >> > >> >> Oops, forgot about that part. :-) >> >> > I'm looking at using the mmap option >> > <http://php.net/manual/en/apc.configuration.php#ini.apc.mmap-file-mask> >> now. >> > Ironically, the same feature which could theoretically allow Fast CGI >> > processes to share memory, >> > < >> http://stackoverflow.com/questions/598444/how-to-share-apc-cache-between-several-php-processes-when-running-under-fastcgi >> > >> > could also theoretically be used to prevent processes from sharing >> > memory. Mmap effectively maps a region memory to a physical file >> > allowing the file to be used as a handle. This would be perfect for >> > chroot'd environments as you could then inherit file system >> > permissions to shared memory permissions. The only problem is that APC >> > is not coded to take advantage of this. Although it provides an option >> > that uses mmap, it's just another way for it to share memory the >> > normal way by placing the opened handle in global memory. It also >> > immediately deletes the file - preventing it from being used as a >> > memory handle. In addition, APC allocates the shared memory in the >> > apache module initialization callback before any chrooting has >> > actually occoured, so to change APC to make use of mmap for real, >> > several changes would need to be made. >> > >> >> Not sure if you prefer APC over xcache, but I think xcache has mmap >> support too. Maybe it does it differently ? >> >> > Hannes >> > >> > On 14 January 2011 19:36, Leen Besselink <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > On Fri, Jan 14, 2011 at 05:02:52PM +0100, Hannes Landeholm wrote: >> > > Hello, >> > > >> > > FYI, I just tested this on my system and it appears that the >> > shared memory >> > > can indeed cross the boundary between different environments, so >> my >> > > assumption that this would be blocked somehow was wrong. As >> > Cronfy wrote >> > > below, the file caching path collision can be fixed by using a >> > directory >> > > structure where the first subfolder in the chroot is unique. >> > This is infact >> > > the case for our system where we have: >> > > >> > > ../user1/www.site1.com <http://www.site1.com> >> > > ../user1/www.example.com <http://www.example.com> >> > > ../user2/www.anothersite.com/ <http://www.anothersite.com/> >> > > .... >> > > >> > > An environment chroot corresponds to a user directory so all >> > paths are >> > > unique. Still, this is an unacceptable security issue as the >> > sites now share >> > > memory with op codes of potentially sensitive information >> > preventing threat >> > > containment on intrusion. For example, hacking www.site1.com >> > <http://www.site1.com> above and using >> > > apc_bin_dump it would be theoretically possible to get the mysql >> > passwords >> > > of www.anothersite.com <http://www.anothersite.com>. >> > > >> > > I'm looking into ways of preventing this... >> > > >> > > Hannes >> > > >> > >> > I think you would need to set an extra value (like php_admin_value >> > or environment >> > variable) from Apache with the real path or sitename or similair. >> > >> > And change the code of the opcode-cache-extension to recognise >> > that extra value as a >> > key/prefix/whatever to prevent them from having the same path >> > inside the opcode >> > cache. >> > >> > A simple change in the path in memory could be enough like: >> > >> > sitename:/path instead of the current /path >> > >> > It could be useful if the name of the the variable is configurable >> > like a >> > php.ini-setting. >> > >> > This might be a bit hackish, maybe there is a better way, I guess >> > it also >> > depends on the code of the opcode-cache-extension. >> > >> > > >> > > On 11 January 2011 19:55, Cronfy <[email protected] >> > <mailto:[email protected]>> wrote: >> > > >> > > > Hello, >> > > > >> > > > >> > > > Also say you have two users who have installed WordPress, you >> > end up with: >> > > >> >> > > >> /home/user1/public_html/wp-config.php >> > > >> /home/user2/public_html/wp-config.php >> > > >> but Eaccelerator (and xcache, APC) only see this: >> > > >> /public_html/wp-config.php >> > > >> as the file path. Do we know if it is serving the correct >> > file when a >> > > >> request comes in from user1 or user2 or whether it thinks >> > they are the same >> > > >> file because of the chroot path? I'm just wondering if anyone >> > has come >> > > >> across this before with peruser + chroot and knows whether >> > these tools are >> > > >> working correctly despite the chroot? Or whether there is a >> > way to feed the >> > > >> full path to these opcode caching tools while using peruser + >> > chroot. >> > > >> >> > > > >> > > > Not sure if it will help, but you may try to add site name to >> > the path to >> > > > make it different: >> > > > >> > > > /home/user1/wordpress-me.com/public_html/wp-config.php >> > <http://wordpress-me.com/public_html/wp-config.php> >> > > > /home/user2/wordpress-yourself.com/public_html/wp-config.php >> > <http://wordpress-yourself.com/public_html/wp-config.php> >> > > > >> > > > Anyway, I agree with Hannes: >> > > > >> > > > >> > > > In fact, it would be a security risk of one environment could >> > access >> > > >> >> > > > the cached PHP files of another environment >> > > > >> > > > And access to shared memory between different users should be >> > thoroughly >> > > > tested. >> > > > >> > > > >> > > > -- >> > > > // cronfy >> > > > >> > > > _______________________________________________ >> > > > Peruser mailing list >> > > > [email protected] <mailto:[email protected]> >> > > > http://www.telana.com/mailman/listinfo/peruser >> > > > >> > >> > > _______________________________________________ >> > > Peruser mailing list >> > > [email protected] <mailto:[email protected]> >> > > http://www.telana.com/mailman/listinfo/peruser >> > >> > _______________________________________________ >> > Peruser mailing list >> > [email protected] <mailto:[email protected]> >> > http://www.telana.com/mailman/listinfo/peruser >> > >> > >> >> _______________________________________________ >> Peruser mailing list >> [email protected] >> http://www.telana.com/mailman/listinfo/peruser >> > >
_______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
