.htaccess: Option FollowSymLinks not allowed here

  • jonloh
  • 05/08/11
  • Offline
Posted: Mon, 2012-12-31 13:21

I have defined the apache template with the following for the directory specific:

<Directory ${HOME}/public_html>
  Options -Indexes +IncludesNOEXEC +FollowSymLinks
  allow from all
  AllowOverride All
</Directory>

But everytime when I create a new virtual server, the AllowOverride All gets appended with the following result:

<Directory /home/test/public_html>
Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch +ExecCGI
  allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/test/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/test/fcgi-bin/php5.fcgi .php5
</Directory>

How can I remove Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch from being automatically added? This causes error 500 with the following error:

.htaccess: Option FollowSymLinks not allowed here


Actually you should not

  • Locutus
  • 10/10/10
  • Offline
  • Mon, 2012-12-31 13:32

Actually you should not prevent those Options from being added, since they are part of a security fix that could cause all your websites to be compromised if one of them gets hacked.


Then is there anyway to alter

  • jonloh
  • 05/08/11
  • Offline
  • Mon, 2012-12-31 21:41

Then is there anyway to alter the options that are being added? Because it doesn't work well with the Options used in .htaccess which Drupal needs it.

Also, I just realized that the whole directive in the directory is being altered. I'm having trouble to find the file that's causing the alteration :(


I've just found out that

  • jonloh
  • 05/08/11
  • Offline
  • Tue, 2013-01-01 10:54

I've just found out that there are other forum posts similar to this, after I used the correct keyword to search.

I guess this seems to be a huge fix to the security hole for FollowSymlinks. In fact, there is a discussion going on in Drupal to change FollowSymLinks to SymLinksifOwnerMatch: http://drupal.org/node/1269780

For those who are hosting your current clients, you can easily update the .htaccess for them to use SymLinksIfOwnerMatch by executing the following bash command:

find /home -name ".htaccess" -type f -exec sed -i 's/FollowSymLinks/SymLinksIfOwnerMatch/g' {} ";"

Do backup your files first before you perform this, just in case something goes wrong :)

Will be updating the post title for better understanding on the issue.


same problem here

  • Smalls
  • 04/09/10
  • Offline
  • Fri, 2013-01-18 15:59

I too am having this issue, no matter what I put in the apache directives, virtualmin appends the same line as the OP posts.

It will also append this line if a backup is restored... incredibly irritating...


oh and by the way, some

  • Smalls
  • 04/09/10
  • Offline
  • Fri, 2013-01-18 16:00

oh and by the way, some websites do not work with SymLinksIfOwnerMatch - namely, magento. It REQUIRES FollowSymLinks to function properly...

this current behaviour is creating a nightmare for me


Hi, As already mentioned,

  • tpnsolutions
  • 02/22/09
  • Offline
  • Fri, 2013-01-18 17:03

Hi,

As already mentioned, the change was part of a patch release of Virtualmin recently. It is not recommended to use FollowSymLinks. While I understand that some scripts dont' work with the recommended, secure method, it may be better to contact the developer of the scripts and ask them to adjust their scripts to help them to enforce better security measures, rather than working on a way to make your system less secure. Though, I do understand that it is a bummer if you are using scripts which don't work quite right with the currently enforced settings.

*** Generally speaking, SymLinksIfOwnerMatch won't be a problem if you have a dedicated copy of a script and related files within the domain's directory and therefore not Symbolically linked. ***

Best Regards,
Peter Knowles
TPN Solutions
 
E: pknowles@tpnsolutions.com
P: 604-782-9342
W: http://www.tpnsolutions.com


Magento works with

  • andreychek
  • 01/04/09
  • Online Now
  • Fri, 2013-01-18 17:03

Magento works with SymLinksIfOwnerMatch, you just need to update the Magento .htaccess files to use that rather than FollowSymLinks.

Any Virtualmin site that uses FollowSymLinks can be exploited to allow that user to read all files in /home. That was creating a nightmare of a different sort :-)

To solve the issue you're seeing, I'd recommend just updating Magento's .htaccess files.

However, if you don't wish to do that, and you are okay with the security issues that exist, you can always prevent Virtualmin from applying that fix in the future by editing the file /etc/webmin/virtual-server/config and adding the line allow_symlinks=1 to the end of the file.

-Eric


what to do?

  • sz00gun
  • 04/04/13
  • Offline
  • Sun, 2013-04-14 08:18

Hello

I have a Magento website and I use the best panel: Virtualmin! I do not want to change it, but as you know Virtualmin doesn't work (500 ERROR) with FollowSymLinks which is in the .htaccess ;(

I know, I can change it to: SymLinksIfOwnerMatch, but there as some security issues ;( Do security issues affect a website or Virtualmin?

I have a dedicated server with 1 admin only, so the others can not log in into Virtualmin panel.

The most important think is having a secured Magento.

What should I do: Should I change option into: SymLinksIfOwnerMatch or change Virtualmin.....

Please advice


Virtualmin doesn't work (500

  • andreychek
  • 01/04/09
  • Online Now
  • Sun, 2013-04-14 20:46

Virtualmin doesn't work (500 ERROR) with FollowSymLinks which is in the .htaccess

Well, Virtualmin configures Apache not to allow that, as allowing it enables users on your system to be able to read any files in /home.

I know, I can change it to: SymLinksIfOwnerMatch, but there as some security issues ;( Do security issues affect a website or Virtualmin?

I would highly recommend changing the htaccess file to "SymLinksIfOwnerMatch", I'm not aware of any security issues with that. It's actually the other way around, not using that is a huge security issue.

You can disable this security fix if you want, though that's not something I'd recommend.

It may not matter as much though if all the users on your system are trusted.

-Eric


Had the same issue with

  • marco1492
  • 10/24/12
  • Offline
  • Thu, 2013-05-16 14:32

Had the same issue with Virtualmin. In my case it worked by changing to SymLinksIfOwnerMatch...


The same issue here

  • aerozeppelin
  • 07/21/13
  • Offline
  • Sun, 2013-07-21 13:32

find /home -name ".htaccess" -type f -exec sed -i 's/FollowSymLinks/SymLinksIfOwnerMatch/g' {} ";"

Solved it for me


Same here

  • Francewhoa
  • 11/14/08
  • Offline
  • Sat, 2013-11-02 21:33

aerozeppelin solution worked. Thanks :)

Detailed instructions at http://drupion.com/resources/downloads/drupal


Better solution

  • philmck
  • 06/24/12
  • Offline
  • Fri, 2014-07-18 09:23

If anyone's still struggling with this, I think I've found a better solution, at least for my situation.

I'm using Virtualmin to manage a VPS that contains several sites, all owned by me or my friends. I use a variety of common content management systems, including Drupal and Magento, both of which try to enable FollowSymLinks in their .htaccess files. Whenever these CMS systems are updated (e.g. using Drush or Magento Connect Manager), my sites stop working with an unhelpful 500 error until I remember that I have to hack the .htaccess files each time.

In my humble opinion, both Drupal and Magento should be fixed to use SymLinksIfOwnerMatch instead. Appropriate bugs/enhancement requests exist for both platforms but don't hold your breath waiting for a resolution.

Meanwhile I investigated the "security vulnerability" that would be caused by enabling FollowSymLinks for these domains on my VPS and it doesn't seem to be too serious. Basically it means one hacked user might be able to access another's files, which would be very bad on shared hosting but not so bad on a VPS owned by one person. So I want to override the Virtualmin behaviour for the affected domains.

The way I found to do this is to go to Services > Configure Website > Edit Directives for the Virtualmin domain in question, find the line that says "AllowOverride All Options=..." under Directory /home/[domain]/public_html and add FollowSymLinks to the end of the list of options so it becomes AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch,FollowSymLinks

It's still a good idea to change a newly-updated .htaccess file for Drupal or Magento to enable SymLinksIfOwnerMatch instead of FollowSymLinks, but at least you won't get a 500 error in the meantime. In fact I think all you need to do is comment out the Options +FollowSymLinks line since Virtualmin enables SymLinksIfOwnerMatch by default.

Hope this helps someone.


No, please do NOT do this. Do

  • lp86
  • 12/04/10
  • Offline
  • Sun, 2014-07-20 13:24

No, please do NOT do this. Do not purposely disable security features just because they are inconvenient. You are just asking for trouble by doing this! All you need to do is remove the invalid syntax from the htaccess file.


Not sure what you mean by

  • philmck
  • 06/24/12
  • Offline
  • Mon, 2014-07-21 06:55

Not sure what you mean by "invalid syntax" - I think you meant "forbidden option" or something.

Just to be clear, I'm NOT advocating any change in Webmin/Virtualmin. I was only discussing situations like mine where there's only one user on a VPS.

I think Drupal and Magento should change though - there's no security risk in using SymLinksIfOwnerMatch as far as I know.


For lazy programmers

  • erwindeclerck
  • 08/26/14
  • Offline
  • Wed, 2014-08-27 02:12

I'm not a bash scripter but something like this does the job for me. No error checking, so take care. If someone is skilled enough to make this script more robust, be my guest!

Add this function to your .bashrc or .profile script (I think .bashrc is most appropriate)

function sedsymlinks(){
 base="/home/"
 public="/public_html"
 files="/sites/default/files"
 rootpath=$base$1$public/.htaccess
 filepath=$base$1$public$files/.htaccess
 
 echo '-------START-------'
 echo 'changing .htaccess +FollowSymLinks to +SymLinksIfOwnerMatch in '$rootpath
 sed -i -e 's/+FollowSymLinks/+SymLinksIfOwnerMatch/g' $rootpath
 head -16 $rootpath
 echo '---------0----------'
 echo 'changing .htaccess +FollowSymLinks to +SymLinksIfOwnerMatch in '$filepath
 sed -i -e 's/+FollowSymLinks/+SymLinksIfOwnerMatch/g' $filepath
 head -16 $filepath
 echo '---------END--------'
}

To activate your new .profile file run:

source .profile
To change your .htaccess files run:
sedsymlinks NAME_OF_THE_VIRT_HOMEDIR
Kind regards, Erwin


This issue has been floating

  • lostandfound
  • 09/20/13
  • Offline
  • Tue, 2014-08-26 12:04

This issue has been floating around for some time. I wanted to draw attention to Apache's viewpoint which is that You should avoid using .htaccess files completely if you have access to httpd main server config file. which can be found at http://httpd.apache.org/docs/current/howto/htaccess.html .

As admins we do have access to the main configuration files so we should be focusing on other solutions, such as using Include which can be found at http://httpd.apache.org/docs/2.4/mod/core.html#include .

I am still getting my head round how to tie everything up properly but using SymLinksIfOwnerMatch with Include in your .conf will be secure and prevent unneeded .htaccess lookups.

Some will be setting up bare bone servers for clients who may not be given configuration access so this will not apply but just wanted to float this to see if any have a solid workflow for setting this up for those who do have configuration access rights..