crnr / timthumb

Automatically exported from code.google.com/p/timthumb
0 stars 0 forks source link

Symlinks in image paths won't work if they go outside docroot #271

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I have two versions of a web site under different vhosts on the same server, 
one is the live site, the other for development/staging. To avoid unnecessary 
duplication of lots of images on the server I have a symlink on the dev version 
to the live version of wp-content/uploads.

Unfortunately, this means that images won't load with TimThumb versions > 2.1 
(or thereabouts).

The reason is that in line 836 (as of 2.8) TimThumb checks that the image path 
is inside the site DOCUMENT_ROOT after resolving any symlinks using realpath.

While by default it is a reasonable security precaution to not allow resolving 
symlinks to outside DOCUMENT_ROOT, I think there should be a way to override 
this.

There are many ways I can think of doing this by amending the getLocalImagePath 
method. One of the simplest is to add the following just after the line with 
//Do not go past this point without docRoot set

if( ALLOW_SYMLINKS_OUTSIDE_DOCUMENT_ROOT && file_exists ($this->docRoot . '/' . 
$src)) return $this->docRoot . '/' . $src;

and adding define( 'ALLOW_SYMLINKS_OUTSIDE_DOCUMENT_ROOT', TRUE ); in the 
config constants at the top.

However, that bypasses many of the other checks and debug logging in that 
method, so isn't more than a quick hack which happens to work for me.

Is there a good reason to completely block resolving symlinks outside 
DOCUMENT_ROOT, or would something along the lines of the above (but properly 
done) be reasonable option to add?

Original issue reported on code.google.com by m...@rowatt.com on 30 Sep 2011 at 1:05

GoogleCodeExporter commented 8 years ago
I agree that it seems odd to block symlinks on Linux hosts.  Especially giving 
the only way its possible to install most PHP apps in a FHS compliant way is to 
use symlinks.

Original comment by russell....@gmail.com on 22 Oct 2011 at 10:53

GoogleCodeExporter commented 8 years ago
If have exactly the same problem here and it's still not solved. I can't 
display images on my website because my host uses a symlink folder called "web" 
as a shortcut for public/www/.
The consequence is that TimThumb finds the image in web/ but then check against 
the realpath() and get two differents paths and of course, throws an "Image not 
found" error.
I really hope for a fix soon.

Original comment by Ehtn...@gmail.com on 28 Oct 2011 at 9:36

GoogleCodeExporter commented 8 years ago
I agree with this issue. I don't want duplicates of many images floating around 
so I've linked to a central image repo.  

Original comment by spence.b...@gmail.com on 1 Feb 2012 at 3:58

GoogleCodeExporter commented 8 years ago
m...rowatt's fix worked for me in the User Avatar plugin for Wordpress.  The 
TimThumb code is located in user-avatar-pic.php.  Of course this hack is likely 
overwritten upon upgrade, but what other options do we have? :)

Original comment by spence.b...@gmail.com on 1 Feb 2012 at 4:26

GoogleCodeExporter commented 8 years ago
This is also a problem if you've used the apache directive "Alias" to direct it 
to a location outside the DOCUMENT_ROOT for the virtual host. Below worked for 
me, should be done with a little more sanity for a real fix, but maybe this 
will help someone else. See ~Line 817 for the below function replace the 
reference to DOCUMENT ROOT with use of realpath & __FILE__

        protected function calcDocRoot(){
                //$docRoot = @$_SERVER['DOCUMENT_ROOT'];
                // Assumption that we are in a themes directory, can this work? up <themename>,themes,wp-content,wordpress. (4)
                $docRoot =  realpath(dirname(__FILE__) . "/../../../../"); 

Original comment by karl.vol...@gmail.com on 18 Feb 2012 at 1:20

GoogleCodeExporter commented 8 years ago
For anyone having this problem, the latest version (2.8.8, r212 in SVN) should 
fix this in most cases. The only case I know which it won't fix is where your 
images are in a directory which has a symlink to outside of your docroot in its 
path (i.e. the image files actually sit outside of your docroot) AND your image 
URI path begins with ../ (which doesn't really make any sense anyway).

Note that if you tried any version from r197 to r207 inclusive you should also 
have seen the problem fixed, but that fix was actually a bug ;-O

Original comment by m...@rowatt.com on 20 Feb 2012 at 7:02

GoogleCodeExporter commented 8 years ago
This is still not fixed in 2.8.10 

<Apache Config>
DocumentRoot /var/www/html
Alias /wordpress /usr/share/wordpress

DOCUMENT_ROOT is /var/www/html while images are 
/usr/share/wordpress/wp-content/*

Original comment by karl.vol...@gmail.com on 11 Apr 2012 at 10:52

GoogleCodeExporter commented 8 years ago
Does work if instead of the Apache Alias directive you symlink the directory? ie

ln -s /usr/share/wordpress /var/www/html/wordpress

If it's not on already, you'll also need the Options FollowSymLinks directive 
set for /var/www/html.

Original comment by m...@rowatt.com on 11 Apr 2012 at 11:25

GoogleCodeExporter commented 8 years ago
Yes a Symlink with FollowSymLinks fixes the issue, however that is not the 
default Red Hat Enterprise Linux configuration preventing timthumb from working 
"out of the box" on an RHEL6 box. Not sure if this is a concern. 

Original comment by karl.vol...@gmail.com on 11 Apr 2012 at 1:07