images stopped showing | htaccess, symlinks, FollowSymLinks, SymLinksIfOwnerMatch

Posted by monti on February 2, 2010 at 7:03am

a message from a hosting company (Feb-2nd-2010) after images disappeared:

Symlinks are no longer safe on the internet. We had to disable them for our whole company.
To get your pictures to work again you need to edit /sites/default/files/.htaccess.

Change the line that says:
Options +FollowSymLinks
to be:
Options SymLinksIfOwnerMatch

Comments

BlueHost/Hostmonster

Posted by HongPong on February 2, 2010 at 9:30am

This is going on with BlueHost/Hostmonster. Thanks for the fix & more info on this thread

http://drupal.org/node/701994

This was also basically what I ran into they did with the auto script altering the root .htaccess but the one that is automatically generated in /sites/all/files/.htaccess has a "bad" directive now. - this directive borks the default file upload:
Notes by jshimota01:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

Now, Bluehost has indeed made a change that will affect me, and also assumedly users of file folders for uploads as well as multisites users too, if I understand drupal a bit. My original .htaccess (at the root folder) from my virgin install looked like this (clipped out...):
.
.
.
# Follow symbolic links in this directory.
Options +FollowSymLinks
.
.
.

Now it looks like this:

# Follow symbolic links in this directory.
# For security reasons, Option followsymlinks cannot be overridden.
#Options +FollowSymLinks
Options +SymLinksIfOwnerMatch

And this should work to get changes to stick:

My fix for me was to ftp into the site, and edit the .htaccess file in the subfolder. (I tried to put their change back, but it just reappeared... :) )

my final .htaccess file in the subfolder looks like:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
# Options +FollowSymLinks (commented by JAS)
Options +SymLinksIfOwnerMatch

Differences for Drupal 5 and 6

Posted by lastar84 on February 2, 2010 at 5:41pm

Any unchanged .htaccess documents in the "files" folder have been the culprit on my Drupal sites.

When Hostmonster made this change to a dozen of my websites (without the courtesy of a notice to customers before or after it occured), they seemed to have tracked down only the .htaccess documents in the root directories of sites, as well as those the root directories of subdomains. They missed any other .htaccess documents, which left them in direct conflict.

In 5, the files directory is typically in the root, whereas in 6, it is typically located at sites/default/files. It's possible that more .htaccess documents are stashed in various locations on various Drupal installations.

One other note if you're trying to locate .htaccess documents: depending on your FTP software, these files may be considered "hidden," and may need to be "unhidden" via options or preferences settings. I believe programs such as FireFTP and SmartFTP come out of the box with hidden files not showing, IIRC.

This fix fails for me

Posted by Keith on August 2, 2010 at 11:58am

After installing a new Drupal-6.x site on Bluehost, the main .htaccess file was changed as described above:

# Follow symbolic links in this directory.
# For security reasons, Option followsymlinks cannot be overridden.
#Options +FollowSymLinks
Options +SymLinksIfOwnerMatch

When I changed Garland's default color scheme, as expected all styling went away. I changed sites/default/files/.htaccess as instructed:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +SymLinksIfOwnerMatch

However, the site is still nuked. Any ideas what I'm doing wrong?

Keith Pierce

Fixing directory permissions solved the problem

Posted by Keith on August 2, 2010 at 3:12pm

I chatted with a Bluehost support person, who graciously tracked down the problem: Permissions on directories sites/default and sites/default/files were 555. After setting them to 755, .css access was restored.

To those frustrated with Bluehost's and other hosts' changes: Yes, they should have notified clients of the changes, but the security threat posed by symbolic links is real. To quote from "Cooking Apache":

Symbolic links are an area in which you need to weigh performance against security and make the decision that makes the most sense in your particular situation. ... If you are primarily concerned about security, never permit the following of symbolic links. It may permit someone to create a link from a document directory to content that you would not want to be on a public server. Or, if there are cases where you really need symlinks, use Options SymlinksIfOwnerMatch, which requires that someone may only link to files that they own and will presumably protect you from having a user link to a portion of the filesystem that is not already under their control.

Keith Pierce

Reply

Posted by lpnschools123 on July 20, 2011 at 7:43am

Symlinks are no more safe on the web. We needed to disable them for the whole company.
To obtain your pictures to operate again you have to edit /sites/default/files/.htaccess.
Alter the line that states:
Options FollowSymLinks
Regards
LPN Program

I had the same problem

Posted by taote on February 2, 2010 at 1:19pm

I had the same problem with all my Drupal websites hosted on HostMonster.

When Optimize CSS was enable, the styles were not showing, and ImageCache was not working neither.

At least you had a message, I spent several hours trying to find out what was happening.

I had the some problem with

Posted by yaph on February 8, 2010 at 10:33pm

I had the some problem with Drupal sites on Hostmonster. A message notifying users of such changes would have been a sensible thing to do. So far I have had no trouble with hostmonster, at least I did not notice, but it's pretty annoying that they did not bother to inform their customers.

--
Ramiro

Still having a problem

Posted by ctb on February 2, 2010 at 1:51pm

Thanks everyone for the posts on this subject. I was up all night before I called Hostmonster and found that they were "having a problem" with Drupal sites. I have a multi-site set up and made the recommended changes to the .htaccess files (they made them for me in the root), then I changed the default .htaccess and the .htaccess in all the subfolders. One just doesn't seem to be rectifying... http://www.phillystagereview.com . I have no idea why. Can anyone help? This is one of my first production sites and we're actively promoting it. Thanks for any ideas!

Problem resolved

Posted by ctb on February 2, 2010 at 2:54pm

Subject closed. I had a files folder with an .htaccess file in the root that I missed. Thanks again.

I've edited the .htaccess

Posted by efarmer on February 2, 2010 at 2:58pm

I've edited the .htaccess folder as well, and it's still not working for me... http://www.simplek12.com

Any other ideas???

You might have add this also

Posted by stevebart9 on February 2, 2010 at 9:22pm

# Don't show directory listings for URLs which map to a directory.
#Options -Indexes

I also had to comment out the Options -Indexes
This is to stop prying eyes into folders but the bluehost guy told me its already on by default and it was throwing up an error,
After I nuked this line on the changed htacess it all came back

Options None

Posted by budgetstockphoto on February 3, 2010 at 5:19am

Along with followsymlinks it seems that bluehost also disabled using "none" and "all" as an option for the Options directive (removing "all" might make sense but removing "none" was just basic stupidity perhaps?).

After a bit of thought about what security hole it might open up I commented out "Options None" and added a new line "Options -Indexes" to the .htaccess file in /files

does anyone know if this might leave me venerable to anything

Hi! Thank you for this

Posted by sideswitch on September 14, 2011 at 11:16am

Hi! Thank you for this post.

I not only got missing images and CSS, but also Internal Server Error 500.

By changing the drupal root's .htaccess file's options to:

#Options +FollowSymLinks
Options +SymLinksIfOwnerMatch

and the .htaccess in / sites/default/files

I was able to get the 'error' to go away, and get the images and css back!

Stew West at siDeSwiTch Web Design Studio
www.sideswitchdesign.com