[peruser] PHP opcode caching and chroot

Leen Besselink leen at consolejunkie.net
Fri Jan 14 11:36:45 MST 2011


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 <cronfy at sprinthost.ru> 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
> > Peruser at telana.com
> > http://www.telana.com/mailman/listinfo/peruser
> >

> _______________________________________________
> Peruser mailing list
> Peruser at telana.com
> http://www.telana.com/mailman/listinfo/peruser



More information about the Peruser mailing list