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 > ../user1/www.example.com > ../user2/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 above and using > apc_bin_dump it would be theoretically possible to get the mysql passwords > of 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]> 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 > > /home/user2/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] > > 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
