[peruser] PHP opcode caching and chroot

Hannes Landeholm landeholm at gmail.com
Fri Jan 14 09:02:52 MST 2011


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


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.telana.com/pipermail/peruser/attachments/20110114/50a68326/attachment.htm>


More information about the Peruser mailing list