My webhost does not allow me to use "Options +FollowSymLinks" because they says it is a security risk.

I have commented out the option from .htaccess at the installation root directory and Drupal 5.0 installed ok.

However when I try to set files and tmp folders Drupal created .htaccess files inside these folders with the +FollowSymLinks option and, as a result, I cannot access or delete these folders!

Now I have two problems:

1. Can I make Drupal work without the FollowSymLinks option?

2. How can I delete or make accessable these files and tmp folders?

Thank you.

Comments

polar-bear’s picture

By the way, following is the actually error message:

<h1>File system</h1>

    * warning: is_file(): Stat failed for files/.htaccess (errno=13 - Permission denied) in /home/kseauk.org/public_html/sig-p/includes/file.inc on line 115.
    * warning: fopen(files/.htaccess): failed to open stream: Permission denied in /home/kseauk.org/public_html/sig-p/includes/file.inc on line 117.
    * Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your files directory which contains the following lines:
      SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
      Options None
      Options +FollowSymLinks
cog.rusty’s picture

Your host has an unusual configuration for... "security reasons". It happens (no comments).

You can disable the +Followsymlinks line (or any or all lines) in Drupal's main .htaccess if your host does not allow them. It is possible that you won't be able to use clean URLs.

The Options +Followsymlinks line in your 'files' directories was added to resolve a bug where you couldn't previews uploaded images. You could delete that line too if it causes problems.

Your access problem to your 'files' directories does not have anything to do with the .htaccess files. It happens because the directories were created by Drupal, so the owner is not you but the web server (usually user 'apache' or user 'nobody').

If the Followsymlinks line in those directories is a problem and you can't delete it, a workaround is:
- ask your host to delete all the 'files' directories for you
- then create them all yourself, using FTP, so that you own them (files, files/pictures, files/images, files/images/temp)
- give them permissions 777 so that the webserver has full access
- create .htaccess files without the offending line in all those directories so that Drupal does not create them again.

Do the same thing before installing any module that you know that is going to create files directories. I know, bother. On most hosts you would just leave them be, owned by the web server or not.

Mike@frazierhome.net’s picture

Another option around the permission issue is to run php from cgi-bin (probably not optimum for very high traffic sites, but works well for most). I run a small webhosting company and I'm now doing this for my customers running PHP apps like Drupal, Joomla, Gallery, etc. By going this route you don't have to deal with the "nobody" files and directories as the php script now runs under your own account, and you don't have to set some directories to 777 to allow access to the owner and the world. Overall its more secure and easier for the customer to manage since they own all of the files (even ones created by the scripts).

lovermann’s picture

Thank you, it worked!
I solved the problem this way using total commander:

  • I connected via ftp to my server directory, where drupal files are placed
  • I deleted /files and /includes
  • I created via command lines directories /files and /includes (mkdir files | mkdir includes). Then I disconnected and connected again in order to see those newly created directories (I don't know, why, but I didn't see 'em the next moment I created them).
  • I copied files to /include
  • I created /htaccess file with text-editor which enabled me saving files in linux format.
  • I copied this .htaccess to /files on my server.
  • I changed access rights to /files
d------’s picture

Hi all...

Same problem here -

warning: is_file() [function.is-file]: Stat failed for files/.htaccess (errno=13 - Permission denied) in /home/somedir/public_html/includes/file.inc on line 115.
warning: fopen(files/.htaccess) [function.fopen]: failed to open stream: Permission denied in /home/somedir/public_html/includes/file.inc on line 117.
Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your files directory which contains the following lines:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

I created the files dir and css dir etc and uploaded a .htaccess with these lines inside. But I still get this same error. Could it be because my .htaccess has windows line endings? Do i need to create the .htaccess on a Linux box?

I cant find the problem here and it has not happened before when installing on non linux servers. Any help much appreciated. Thanks!

Update:


The problem was with the line endings... Anyone else having trouble, then try and save your .htaccess with unix line endings then upload to the files directory. Also dont forget to chmod the correct permissions on the files and folders too.

psiska’s picture

Hi

I was experiencing some problems with BUEditor and user pictures because of the .htaccess files drupal creates automatically with includes/file.inc.

My webhost does not allow any .htaccess files, i can just configure some options globally in the hosting control center. Removing the autogenerated .htaccess files got my user pictures, bueditor and probably other things that have not been working so far, working.

I know this is probably a pretty straight-forward and insecure approach as the .htaccess files are put in the directories for some security reasons too, but i had to comment out the lines in includes/file.inc (file_check_directory function) where drupal generates the .htaccess files as following:

function file_check_directory(&$directory, $mode = 0, $form_item = NULL) {
  $directory = rtrim($directory, '/\\');

  // Check if directory exists.
  if (!is_dir($directory)) {
    if (($mode & FILE_CREATE_DIRECTORY) && @mkdir($directory)) {
      drupal_set_message(t('The directory %directory has been created.', array('%directory' => $directory)));
      @chmod($directory, 0775); // Necessary for non-webserver users.
    }
    else {
      if ($form_item) {
        form_set_error($form_item, t('The directory %directory does not exist.', array('%directory' => $directory)));
      }
      return FALSE;
    }
  }

  // Check to see if the directory is writable.
  if (!is_writable($directory)) {
    if (($mode & FILE_MODIFY_PERMISSIONS) && @chmod($directory, 0775)) {
      drupal_set_message(t('The permissions of directory %directory have been changed to make it writable.', array('%directory' => $directory)));
    }
    else {
      form_set_error($form_item, t('The directory %directory is not writable', array('%directory' => $directory)));
      watchdog('file system', t('The directory %directory is not writable, because it does not have the correct permissions set.', array('%directory' => $directory)), WATCHDOG_ERROR);
      return FALSE;
    }
  }

/* UNCOMMMENTED BECAUSE WE DON'T WANT TO HAVE .htaccess FILES IN DIRS (not permitted by host)
  if ((file_directory_path() == $directory || file_directory_temp() == $directory) && !is_file("$directory/.htaccess")) {
    $htaccess_lines = "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006\nOptions None\nOptions +FollowSymLinks";
    if (($fp = fopen("$directory/.htaccess", 'w')) && fputs($fp, $htaccess_lines)) {
      fclose($fp);
      chmod($directory .'/.htaccess', 0664);
    }
    else {
      $message = t("Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your %directory directory which contains the following lines: !htaccess", array('%directory' => $directory, '!htaccess' => '<br />'. nl2br(check_plain($htaccess_lines))));
      form_set_error($form_item, $message);
      watchdog('security', $message, WATCHDOG_ERROR);
    }
  }*/

  return TRUE;
}
rosell.dk’s picture

I did a similar hack in D7
In includes/file.inc, I let the file_create_htaccess() return immediately.
Did you experience any problems with this approach?

Zupri’s picture

Post Installation Tweaks

Drupal 7 might create an .htaccess file in your /sites/default/files directory containing lines starting with the word "Options". This will cause files, such as images, not to appear on your site. You can comment those lines out if you observe your images not loading, or do a bit of pre-emptive work and create a blank .htaccess file yourself (which might stop Drupal from creating its own version).

The .htaccess file will look like this:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

Change it to:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None
#Options +FollowSymLinks

source :http://techcommons.stanford.edu/book/export/html/307

note: it is better if you create .htaccess file by your own, containing

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None
#Options +FollowSymLinks

then save and replace the .htaccess file in your /sites/default/files directory
and set permission to 555

tested on me

whereisaaron’s picture

You can, and probably should, replace all uses of FollowSymLinks with SymLinksIfOwnerMatch. There are several files in a Drupal install, but you can fix them all with a search-and-replace command similar to:

find /path/to/website -name "." -type f -print -exec sed -i 's/FollowSymLinks/SymLinksIfOwnerMatch/g' \{\} \;

It appears this has been patched in Drupal 8, but there are some difficulties back-porting it to 6 and 7.

"Use +SymLinksIfOwnerMatch instead of +FollowSymLinks option in .htaccess - Security"
https://drupal.org/node/1269780

This has become a standard precaution for many shared hosting situations, where you don't want a website breach to become an entire server breach.

"From a Site Compromise to Full Root Access – Symlinks to Root – Part I"
http://blog.sucuri.net/2013/05/from-a-site-compromise-to-full-root-acces...

"Virtualmin virtual-server module version 3.96 released [SECURITY]"
http://www.virtualmin.com/node/24260

john_b’s picture

In Virtualmin it is possible to change the default virtual host configuration ('template') to override this problem.

Who knows why the D7 has not been modified - the Failed Testing (in the linked issue above) looks like a testbot error? That kind of road block can be hard to get past, especially now that so much of the available development effort has to go in to Drupal 8.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Vayira’s picture

Hi!

I'm trying to move my Drupal 6 site to a new server with virtualmin and most of my images & css files are not loading. This seems to be to do with the +FollowSymLinks issue. I put +SymLinksIfOwnerMatch which doesn't produce a server error but I still don't get any images .

I'm using Drupal 6.34

Can't figure out how to move forwards

john_b’s picture

The lack of images may be unrelated.

However, the alternative is approach is to override this behaviour of Virtualmin. In a file manager or from command line, go to /var/apache2/sites-available. Find the .conf file for the domain in question. Manually edit it to allow FollowSymLinks instead of SymLinksIfOwnersMatch. Restart Apache. This is not really a security risk if you control the server because it is a risk of a different account on the server infecting the account you are changing. This will take the problematic Virtualmin behaviour out of the equation, so see what happens.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Vayira’s picture

Being as the server is new with few sites on it I tried changing the configuration of apache to allow FollowSymLinks and that fixed the image problem so that was definitely the issue.

As I understand it the security risk means that if a Drupal installation gets hacked (as happened recently) then the FollowSymLinks directive could allow access to the whole server. Is that right?

john_b’s picture

I guess a malicious symlink could be added if the hacker hacked a site running php as Apache owner, as happens when running php using mod_php. So yes, that seems about right. I cannot see how a symlink into a different site could be executed if that site runs php as account owner. However, I could be wrong about that. There is a Drupal core issue for switching Drupal to the Virtuamin setup by default: https://www.drupal.org/node/1269780

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Vayira’s picture

Yes I've see that core issue but it doesn't seem to be resolved.

I'm having to run the site as apache as it won't work with FCGId
Seems to be the issue here
https://www.virtualmin.com/node/30441

So I'm stuck with an insecure setup? Or can I get drupal to work using FCGId instead of mod_php?

john_b’s picture

It is not that insecure unless there are other sites on the server which are opening security holes.

If setting the sites on the server, one by one, to use FCIGd in the Virtualmin interface does not work, normally you get it working by setting the ownership of the website folders manually to be the same as the owner of the account. If it does not work, read the error log to see why not, 'rinse and repeat.'

Sometimes mod_php is better as FCIGd has certain disadvantages. Best practice seems to be php5-fpm with Apache (or with nginx if you prefer), but Virtualmin does not support it out of the box AFAIK, and it can be a little more tricky to get it working anyway.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Vayira’s picture

Hi tried changing to FCGId and then checked the apache log to see if I learnt anything. However, there are no errors generated, all that happens is that instead of running the php script my browser offers to download the php code as it is.

john_b’s picture

That is an unrelated problem to the main part of this thread. It is because Virtualmin is not properly set up. Maybe deleting the virtual host and recreating it for fcgid would do it. However, that is a pain and should not be needed. You can start here https://www.virtualmin.com/node/25521 and Google for more answers.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors