Incorrect warnings about insecure .htaccess file in /tmp directory from SA-CORE-2013-003

same here

Same here, and looking at my server I find the Apache processes running amok? (load 40+)

Reverting the .htaccess and restarting Apache -> all back to normal.

Edit: nevermind, this seems to be a different issue, will file a new bug.

I found I had to add ../../ to /tmp on the file-system page to have it find the .htaccess file correctly. Obviously you need to add the correct amount of ../ relevant to your installation.

I'm getting the same error too.
I've tried deleting the existing .htaccess file and saving the file system configuration as advised in SA-CORE-2013-003.
I've also uploaded the .htaccess as advised in SA-CORE-2013-003 and I still get the same warning.

What's worked for me in both Drupal 6 and Drupal 7 installations is to change the tmp directory location from /tmp to ./tmp thus preserving absolute addressing.

Confirming that woodp's tweak *apparently* fixed the issue for me as well.

I've just tried the change described in #5 and it worked.

Thanks

Confirming #5 fix.

I went to http://mydrupal.com/config/media/file-system
and change there the temporary directory to "./tmp"

In my case the directory tmp didn't even existed although the path was included in the above field.
Thanks woodp!

#5 did not work here. renaming /tmp was not accepted to be saved.

Changes my temporary directory path to
../tmp
Problem solved, thanks guys!

A few solutions here removed warning for me, but it does not give me a green check either (simply removed Temporary Files Directory row in Status report) - -not sure if this is by design or not, but a green check would be reassuring.

Asking for a green check for everything that's working properly might make for an unrealistically long list. I have over a dozen Drupal 6 and 7 installations and they're all fine with the ./tmp setting.

It's not unusual for linux to require an explicit directory reference (./ instead of /), so you wouldn't expect an issue here.

Hi,

Much appreciated if anyone can help. I just finished updating my core from 7.23 to 7.24 and I received two error messages (SA-CORE-2013-003), one of which deals with the temporary files and the other deals with public files. I tried to update my site by going through the update.php process, however, I couldn't go through it because i received a message that said I need to review updates: 'front page & administration'. I check all of my available updates, and everything is up-to-date.

And also, it looks like my /tmp is not located within my public_html as one resource online noted that this file set-up is apparently not helpful for solving this issue.

Thank you again for any assistance!

The ./tmp worked for me as well! Thank you, woodp! If anyone has a solution on how to resolve the public files directory error, it would be greatly appreciated!

@t3rtle,

Your answer is in the "Solutions" paragraphs of https://drupal.org/SA-CORE-2013-003

To fix this issue, you must edit or replace the old .htaccess files manually. Copies of the .htaccess files are found in the site's files directory and temporary files directory, and (for Drupal 7 only) the separate private files directory if your site is configured to use one. To find the location of these directories, consult the error messages at admin/reports/status, or visit the file system configuration page at admin/settings/file-system (Drupal 6) or admin/config/media/file-system (Drupal 7).

Go onto your server, navigate to each directory, and replace or create the .htaccess file in this directory with the contents described below. Alternatively, you can remove the .htaccess file from each directory using SFTP or SSH and then visit the file system configuration page (admin/settings/file-system in Drupal 6 or admin/config/media/file-system in Drupal 7) and click the save button to have Drupal create the file automatically.

So just remove /sites/default/files/.htaccess and then visit and save the configuration page.

#5 works fine for me (Drupal 7)
Thanks!!

Are the changes to .htaccess only to be applied to those in the files folders?

Are any of these changes to the .htaccess to be added to the one in the web root of the drupal site?

I have a Warning : mkdir() [function.mkdir]: when I tried to change th directory of the tmp folder. What can I do ? it's ok in fact I just have to add little more dots according to my configuration. ../../../tmp

Same problem here (Drupal 6). There was no .htaccess file in /tmp so I added one as specified (including the additional 'deny from all' line) but to no avail.
I also tried changing the config to .tmp in file system but it wouldn't let me.
I also tried deleting the .htaccess files and saving my settings in file system but that didn't work either.

Is there supposed to be an .htaccess file in /tmp?
Is it at the root level, or should it be in /tmp/files?

@marjory add as many ../ as folders between your /tmp folder and your application folder. Drupal will create the .htaccess file by itself

Yasmina. My tmp folder is at the top level. My Files Setting is /tmp and it will not allow anything else (eg .tmp, ..tmp, tmp) - it just says that the directory doesn't exist.

I had the same issue and now it works perfectly. What do you mean by top level? if it's only one level left, ../tmp should be working.

Please ignore any warning on .htaccess in the /tmp directory (that is, tmp in system root). The directory is not accessible via the web. If you have tmp below the webroot, do heed the warning.

Do not change /tmp to ./tmp; This creates a webaccessible tmp relative to the drupal root and is less secure.

It is at the same level as public_html, directly beneath my home directory.
If I put in ../tmp I get 'The directory ../tmp is not writable'

@Heine what do you suggest exactly let /tmp as it is ?
@marjory if it's beneath it's normal the ".." go above. Try to give the absolute path then ... or not if we don't have to change it ... I don't know anymore what we are supposed to do

I have tried every combination of ..../tmp, etc. None work.
Heine - if you're right, then this error is a bug isn't it?

There may be a few different issues going on here:

1. If you believe you've modified the .htaccess file in the temporary files directory but are still getting the error message on the Status Report page, make sure you modified it in the correct place. If your site is configured to use "/tmp" (as many are) that means the /tmp directory in the system root (at the top level of the web server's file system). It is not relative to your Drupal installation; it is not the same thing as "tmp" or "files/tmp".
2. If you don't have permission to remove or edit the existing .htaccess file in /tmp, it's OK because the .htaccess file isn't necessary as long as the temporary files directory isn't in the web root (which is the case for /tmp). You can ignore the error messages for now.
3. Switching your configuration on the File System settings page to put the temporary files directory somewhere else is safe as long as that somewhere else is not publicly accessible over the web. Using "./tmp" (as in #5) is publicly accessible by definition, and therefore cuts down on the security of your site. The .htaccess file which Drupal puts in there does try to block public access to the directory, so it may still be OK, but it's less safe overall.

As for what to do about this:

1. We need the warning about the .htaccess file in the temporary directory because in general some sites do have it in a web-accessible location (in fact, this is Drupal's default behavior if it can't find anywhere else to put it). However, we could try to suppress the warning in cases where we don't need it. In general this is difficult or impossible to detect, but we could special-case "/tmp" since that is the most common situation (and I can't imagine any way a directory like /tmp would be web-accessible).
2. We should consider something like #2141137: The .htaccess file cannot be overwritten to allow the web server to automatically write the .htaccess file for you. We thought about doing this automatic update as part of the security release, but it was too risky for a security release and we didn't have enough resources to fully test it.

Re #17:

Are any of these changes to the .htaccess to be added to the one in the web root of the drupal site?

No, the .htaccess file at the top of the Drupal installation should not be changed. Only change the ones mentioned in the security announcement (the ones in the various files directories).

Closed several similar issues as duplicates.

We could also try to document this better (in the security announcement or elsewhere) if anyone has suggestions.

@David_Rothstein

No, the .htaccess file at the top of the Drupal installation should not be changed. Only change the ones mentioned in the security announcement (the ones in the various files directories).

Thank you. This helps clarify the security announcement.

Thank you, woodp. However, I'm still having trouble with the idea of removing/editing this file (.htaccess) as it seems to only include pictures, styles, and at least for me, multiple images/data that I need on my site.
When I tried to look for .htaccess, I could not find a file or folder that is given this title, but when I did a search in my directory, I was lead to what is the group of files that consist of pictures/styles and my images.

I guess I should just try adding a .htaccess folder with txt contents within the tmp folder to see if that works?

Thank you.

subscribe

I found you need to manually remove the existing .htaccess files before visiting admin/config/media/file-system and clicking SAVE. The system is unable to overwrite the existing files but can create new ones. This wasn't clear in my reading of https://drupal.org/SA-CORE-2013-003

When I make the tmp file in the root manually with 777 and put the .htaccess file in it. Then change "/tmp" into "tmp" in
inadmin/config/media/file-system, the error in status report disappeared.
Is this secure enough?

PipB, I don't think so. By removing the slash, you've made the tmp directory relative to your web root, and in your web root, which is not advised. And 777 makes the folder writable by the entire world. It only needs to be writable by the apache user.

Right, "tmp" is treated the same as "./tmp", so see #23 and #27 for more details.

I think you're better off just leaving it at /tmp, and if you don't have edit rights on that directory (to be able to modify the .htaccess file and make the error messages go away), just live with the error messages until this issue is fixed.

I have a VPS.... so have access to all permissions, etc. I modified the new .htaccess files and placed in the sites/default/files and the /tmp folder which is outside the /public-html/ directory where all the drupal files reside. What should the permissions on the .htaccess file in the /tmp directory be? currently I've got it set at 444... tried 644 and it didn't remove the error so I changed it back to 444. It seems kind of odd that what is referenced for the /tmp folder seems kind of incorrect as the path doesn't really take you to the "tmp" folder but ./tmp does. Thanks

The problem is /tmp is outside the drupal install. Drupal cannot put the new .htaccess file into the tmp folder because Drupal does not find the tmp folder. That's why the error in the status report exists. The folder /tmp is still not secure after updating to Drupal 7.29 I think. The vulnerability exists.
I can't find this tmp-folder on the server to put there the .htacces manually. I've got no rights to see this folder on te server. The webserver already uses this tmp-folder en will not show this.
Can someone confirm this is correct?

I installed security_review (https://drupal.org/project/security_review) to check security.

The report shows "PHP files in the Drupal files directory can be executed", even after manually edited the .htaccess file in the files-dir. with the recommended code for D7(see below). The report-details are: "Executable PHP in files directory
The Drupal files directory is for user-uploaded files and by default provides some protection against a malicious user executing arbitrary PHP code against your site.
Read more about the risk of PHP code execution on Drupal.org. The .htaccess file exists but does not contain the correct content. It is possible it's been maliciously altered.."

The adviced code for .htaccess for upgrading to D7.24 from:https://drupal.org/SA-CORE-2013-003, The Security Report said the code seems to be not secure:
# Turn off all options we don't need.
Options None
Options +FollowSymLinks
# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
# Override the handler again if we're run later in the evaluation list.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
# If we know how to do it safely, disable the PHP engine entirely.
php_flag engine off

I have resolved with three quick & dirty actions:

1. For "Temporary directory": change from " /temp " (or other path) into " yourdomain.xxx/admin/config/media/file-system " to " temp " and SAVE
2. For "Public file system path": remove current .htacces file from /sites/default/files and after go to "yourdomain.xxx/admin/config/media/file-system" and press SAVE
3. For "Private file system path": remove current .htacces file from /sites/default/files/private and after go to "yourdomain.xxx/admin/config/media/file-system" and press SAVE

These simple three actions make to return smile on your face :)

Ciao
Fabrizio

I don't know whether or not this is a known issue, since I can't seem to find it in any of the related forums. I updated my htaccess file as suggested and it messed up some of my builder panels. I commented out the "Deny from all" line and everything went back to normal. Basically, the problem was that all of my panel builder panes were showing in separate rows at 100% width. I'm not sure why it "broke" or how commenting out "Deny from all" fixed it, but I thought this should be noted in a forum.
Thanks.

remove .htaccess files under public file folder, private file folder and tmp folder give me green report

#42 WORKS 100% for me.

Remove .htaccess files. You can then navigate to /admin/config/media/file-system and hit save to let Drupal recreate the proper files (as stated in the SA).

As Heine in #23 says, do NOT change /tmp to a relative path. Not that it is accessible from the web with the proper .htaccess file, but it is a matter of order; and an extra security layer.

I am not totally sure about other systems but in Ubuntu systems the directory /tmp is accessible by Apache (www-data) because it is 777. If www-data places there a .htaccess file (as I believe Drupal does) with read-only attribute then Ubuntu should not remove it after a restart.

Of course for this to happen PHP safe mode must be off. If safe mode is on then you have to place tmp inside the document root.

#42 CRASHED MY SITE

I'm running WHM/cpanel vps and when I removed the .htaccess from the html_public folder the site crashed. I went to try and copy a .htaccess from one of my other sites but when I came back to the crashed site the server had recreated this file. I don't know if I screwed something up when I was getting a little lag on my system (click on something you don't entirely realize you clicked) but I couldn't for the life of me get the site to give me anything besides the white screen of death. I got lazy and contacted my ISP to reinstall from a prior backup the da before. if you're using a cPanel admin for your site I don't recommend deleting the .htaccess file in the public folder.

P.S. I also don't understand why providing the correct path the the actual "TMP" folder on the site is a bad thing security wise. For the time being I've opted to live with the error message but /tmp is not the correct path to the folder/director, "./tmp" is since it exists outside the public_html folder

I completed the upgrade and using the ./tmp method, have a clean slate in the status report. However, with these put in, I do not have images displaying anywhere on the site, but I can see them via SSH and FTP.

What happened with my images?

EDIT::
Looks like I put the Deny from all in the .htaccess in /sites/default/files. Removing it, and only having the Deny from All only in the ./tmp directory fixed my images.

Given that it might be difficult to run a reliable test to automatically determine whether /tmp is web-accessible, it seems like a good solution for now might be to simply enable admins to indicate with a checkbox that their directory is not web-accessible in order to suppress the notices.

However it is addressed, I think it is important so people don't get used to paying less attention security notices because of a known false positive.

I totally agree with #46

chartmann and Tregonia, I had similar issues and I couldn't figure it out until I saw your comments. I had also put the "Deny from all" in the .htaccess of both the public and private files directory, instead of just the private directory.

I'm using the responsive theme AdaptiveTheme, in case anyone else is searching for the solution to what seems to be a sudden stretching of some images and panels, after applying this core update.

My /tmp directory is in the system root (top-level) directory on a linux shared server running Apache 2.2.25. I added the .htaccess file per the instructions and I still have the warning re: the /tmp directory. This seems to be happening for both 6 and 7 users and the system root is the typical location of the /tmp directory. Thanks for the warning on adding the . before / and it may take a little digging beyond the first few hits of researching the problem to find out that it's better to ignore the warning than make it go away.

this is the same issue as https://drupal.org/node/2140629 just add full path to the tmp directory above your public_html

Home » Administration » Configuration » Media » File System

Change the temporary directory from /tmp to ./tmp and be sure to check " Public local files served by the webserver."

Everything should work fine then.

Home » Administration » Configuration » Media » File System

Change the temporary directory from /tmp to ./tmp and be sure to check " Public local files served by the webserver."

Everything should work fine then.

Too much text I don't understand.
Too much contradicting suggestions.
Too much confusing stuff to go through.

I have just updated to 7.29 and I thought this would be solved automatically and forever, but it is still appearing.
I have seen several years old issues on this from D6, so do I have to understand this is an OOOOOLD issue that still hasn't been solved?
I have never touched nor done anything about this due to the obvious controversy that apparently has been existing for several years now on this issue, specially the multiple messages on changing to "tmp" or "./tmp" which then have the same number of replies insisting in that not being the way to solve it.

Is it possible for someone to *BLEEP* explain what file or code has to be made or adapted and how, in less than five lines? (NOT references to other issues or php/SQL manuals, please!!!)
if not I - and I guess many others with me - will just fully forget about it and mark it as yet another Drupal mistery, which we hope will not shoot us in the back, when finally having the website somewhat operational, even if at only 30% of it's intended functionallity.
Thank you

Have you even read comment #27 before going off on your little rant here?

I have just updated to 7.29 and I thought this would be solved automatically and forever, but it is still appearing.
I have seen several years old issues on this from D6, so do I have to understand this is an OOOOOLD issue that still hasn't been solved?

This issue has only been around for eight months, as the issue summary shows. Furthermore, it would only be fixed in a new D7 release if this issue were marked as fixed; which it's not. So what on earth made you believe it would get fixed in 7.29?

if not I - and I guess many others with me - will just fully forget about it and mark it as yet another Drupal mistery, which we hope will not shoot us in the back, when finally having the website somewhat operational, even if at only 30% of it's intended functionallity.

If everyone had your lousy attitude, nothing would get fixed. I find your lack of respect appalling.

• You obviously didn't read through the entire issue
• You then demand someone offer you the perfect solution on a silver platter
• In the same post where you ask for help with Drupal, you claim you hate Drupal (your profile and user name say so too)

Have you ever considered:

1. Insulting people and/or their work does not motivate them to help you?
2. Ranting in an issue does not contribute to it at all? On the contrary: it adds more clutter for people that do want to help to sift through.
3. A career change? I mean: it's obvious you hate Drupal, why stick around to get frustrated even more?

Couldn't agree more with #54; kristiaanvandeneynde.

Very well said!

Excuse me for being a relative Newbie, but I am still confused by the discussion.

Like everyone, I am getting the Status Report Error:
"Temporary files directory Not fully protected
See http://drupal.org/SA-CORE-2013-003 for information about the recommended .htaccess file which should be added to the /usr/tmp directory to help protect against arbitrary code execution."

I do not have a /tmp directory, either at the root of my file system or in my Drupal installation files. The fix everyone says is to change the /usr/tmp to ./tmp in the file system. Is that or is it not unsafe? I'm on a shared hosting plan, so is the /tmp file actually with the hosting co, and is the change needed?

If it is ok to put a /tmp file in my Drupal installation, should I create a .htaccess file and what should it say besides the "Deny from all" language?

Thanks!!

If you are on Linux hosting, chances are you have a global /tmp you can write to, regardless of whether you're on shared hosting. In that case, just put the field to /tmp and ignore the warnings. Those warnings don't mean jack when your temp folder is outside of the webroot.

(Which is mainly what this issue is about: people with a correct temp folder still receive warnings)

Sorry for being dense: "just put the field to /tmp "
Do you mean in the File System path? Right now, it says /usr/tmp. So you are saying by just having /tmp it will be above my account?
(In that case, does the hosting company protect?)

Thanks a million.

Normally, the temp folder can be found under /tmp.

If the path starts with a forward slash, it means it starts from the root of the system. Usually, short paths starting at the root are above your webroot and should be safe. In your case it could very well be at /usr/tmp...

Delete existing .htaccess files from your tmp and private folders.

Run cron to create the missing .htaccess files.

Drupal 7.32 .htaccess code that is created for tmp and private folders:

Deny from all

# Turn off all options we don't need.
Options None
Options +FollowSymLinks

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

I prefer to fix this issue by modifying the httpd.conf file rather than by creating .htaccess files.
After all, apache only recommends using .htaccess files when you don't have access to the apache config files.
But Drupal doesn't seem to recognize this way of fixing it and always gives me a "not fully protected" warning on the status screen.
It has been an annoyance for quite a while.

Doesn't anyone else prefer to do it this way? Any interest in modifying drupal so that it doesn't complain about having these silly .htaccess files out there?

> Doesn't anyone else prefer to do it this way?

Yes. It is much safer to do it in the httpd configuration and also forbid overrides. Also, a /tmp .htaccess is silly and won't work if multiple sites try it. This either needs a hook_requirements_alter or a "quit_yer_whining" variable check on the .htaccess checks.

> This either needs a hook_requirements_alter or a "quit_yer_whining" variable check on the .htaccess checks.

I'm happy to see that you feel this way, too. yeah, personally, i always forbid overrides in the apache config file.

You know, I was actually thinking a more drastic change may be preferable.
like completely changing the system.install file lines 256-287 (Drupal 7.32) to do ini_get commands on all the "files" directories to check if php engine is enabled instead of just scanning .htaccess files. maybe doing some additional ini_get commands to ensure that the php options are good. wouldn't that be a better way to do this check?

#40 worked for me.

Following up on this from #27:

We need the warning about the .htaccess file in the temporary directory because in general some sites do have it in a web-accessible location (in fact, this is Drupal's default behavior if it can't find anywhere else to put it). However, we could try to suppress the warning in cases where we don't need it. In general this is difficult or impossible to detect, but we could special-case "/tmp" since that is the most common situation (and I can't imagine any way a directory like /tmp would be web-accessible).

Attached are patches for Drupal 7 and 8 that attempt to do that but a little more generally, using sys_get_temp_dir() rather than /tmp. (It is hard for me to imagine a scenario where the result of sys_get_temp_dir() is web-accessible; hopefully that is a safe assumption to make.)

There is probably more that could be done here, including special-casing some of the other hardcoded directories that can be found in file_directory_temp() (Drupal 7) and FileSystem::getOsTemporaryDirectory() (Drupal 8), but this is hopefully a good start.

It is hard for me to imagine a scenario where the result of sys_get_temp_dir() is web-accessible; hopefully that is a safe assumption to make.

Actually it does seem to be possible though, because this is configurable in php.ini and someone could have put something crazy there. So maybe it would be better to just hardcode /tmp (and the equivalent for Windows) in this patch instead... I am not sure.

[Complete One-step Solution for newbies who stumble upon this page because of this ongoing problem, which existed back in D7] Example: Drupal 8.4.2 online shared webhost; and all Drupal 7 sites on same webhost

You may want to undo any other changes you have made while trying to resolve this issue.

This worked for Drupal 8.4.2 online shared webhost.

This also has worked for years with Drupal 7.

The Total One-step Solution:

Go to your Drupal 8, or Drupal 7, configuration page:

admin/config/media/file-system

Change the field 'Temporary directory' from...

/tmp

...to...

~/tmp

Click the page-bottom button "Save configuration".

Note: I have also read elsewhere on drupal.org that in addition to ~/tmp, the following may also work-- I do not think it matters what path and folder-name you use, so long as it is not the one which is currently giving you problems:

• ../tmp
• tmp
• /tmpdir
• tmpdir
• Etc.

Re-rolled for 9.2

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Re-roll patch #75 against Drupal 10.1.x
Patch #75 is not applied for Drupal 10.1.x so Inter-diff file is not added.

Checking patch core/modules/system/system.install...
error: while searching for:
      // Check for the string which was added to the recommended .htaccess file
      // in the latest security update.
      if (!file_exists($htaccess_file) || !($contents = @file_get_contents($htaccess_file)) || strpos($contents, 'Drupal_Security_Do_Not_Remove_See_SA_2013_003') === FALSE) {
        $url = 'https://www.drupal.org/SA-CORE-2013-003';
        $requirements[$htaccess_file] = [
          'title' => new TranslatableMarkup($protected_dir->getTitle()),

error: patch failed: core/modules/system/system.install:577
error: core/modules/system/system.install: patch does not apply

I think this is outdated. The last report is 8 years ago on Drupal 8.5. That is about the same time that discussion on the problem in the issue summary stopped as well.