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
