Link to useful information about .htaccess and directory protection

Usability is preferred over UX, D7UX, etc. See https://www.drupal.org/issue-tags/topic

The warning doesn't tell me where the temp directory even is.

Yes it does, it's right there in the message (in italics): "....for information about the recommended .htaccess file which should be added to the /tmp directory to help protect against...."

Is there a way to make this more clear?

I'm also linking to another issue that would make this message go away altogether in many cases, but it's definitely still worth improving the documentation here for the cases where it does need to be displayed.

Perhaps something like "... which should be added to your site's temporary files directory (located at /tmp) to help protect against..." would be better?

Came across this post thanks to David Snopek (Drupal Security Team).

Recently encountered this same message on Drupal 8.8.2 after the upgrade from 8.8.1 (manually via tarball) where this issue was not noted with 8.8.1.

On a parallel system (the difference is Ubuntu versus CentOS (=issue here system) as the LAMP stack OS), this is not showing up though. I find this a bit odd and unusual since minus the OS layer, the Drupal stack, site, and modules are nearly identical.

Questions and/or feedback are welcomed. Thanks in advance.

Same issue here v. 8.9.3
I have a private folder outside from the web root folder, both on local and production server.
I have tried to use the drupal 7 htaccess with no results.

How to solve this error?

The same here with drupal 9.1.9

This persists in Drupal 9.3.3.

As for comment #5 by David_Rothstein:

Yes it does, it's right there in the message (in italics): "....for information about the recommended .htaccess file which should be added to the /tmp directory to help protect against...."

In version 9.3.3 the warning message has become:

TEMPORARY FILES DIRECTORY
Not fully protected
See https://www.drupal.org/SA-CORE-2013-003 for information about the recommended .htaccess file which should be added to the temporary:// directory to help protect against arbitrary code execution.

Notice that the path /tmp is replaced by the stream wrapper temporary://, and if you're not familiar with stream wrappers, you'll have a hard time figuring out where the temp directory is.

I think this is worth fixing. While most Drupal alumni should be able to figure it out, it is frustrating for our new community member to be hit by such unhelpful guidance when this one bites them.

So I'll have a go at fixing this core issue. My plan is:

1. Create an updated documentation page on Drupal.org, loosely based on my replies in forum post: Error: Temporary files directory that explain how to fix this in plain language.
2. Add a link to this documentation page in the warning displayed in the status report (I think the warning is located on line 616 in the file system.install).

Suggestions for a suitable location for this documentation page will be appreciated.

Other feedback shall also be appreciated. I won't move status to "Needs review" until I've actually done this.

I've added a documentation page about how to fix this that I hope is more up to date than SA-CORE-2013-003:

Please visit: https://www.drupal.org/docs/installing-drupal/temporary-files-directory-...

If you think it can be improved, please tell me, or Be Bold, just go ahead and improve it yourself, by pressing "Edit".

I also think that the stream wrapper (temporary://) is not helpful. Users want to see what directory they need to look in, '

I also think the link to the SA is not helpful. I've linked to it on the documentation page, but shall remove from the warning.

So the plan now becomes:

1. Create an updated documentation page on Drupal.org that explain how to fix this problem in plain language.
2. Replace the stream wrapper temporary:// with the actual file system path.
3. Replace the link to the SA with a link to this documentation page in the warning displayed in the status report.

Added this to the issue summary under the heading "Proposed solution"

Uploaded patch.

Please review.

Fixed CS errors and uploaded new patch.

Please review.

Drupal 8 (referenced in the issue summary) is past EOL.

+++ b/core/modules/system/system.install
@@ -604,16 +604,17 @@ function system_requirements($phase) {
-          'description' => t('See <a href=":url">@url</a> for information about the recommended .htaccess file which should be added to the %directory directory to help protect against arbitrary code execution.', [':url' => $url, '@url' => $url, '%directory' => $protected_dir->getPath()]),
+            'description' => t('See <a href=":doc">@doc</a> for information about the recommended .htaccess file which should be added to the %directory directory to help protect against arbitrary code execution.', [':doc' => 'https://www.drupal.org/docs/installing-drupal/temporary-files-directory-not-fully-protected', '@doc' => t('this documentation page'), '%directory' => $service->getTempDirectory()]),
         ];

This message is being output for public, private and temporary (see ::defaultProtectedDirs) so I don't think to a documentation page specifically about temporary files.

Can we make that page generic enough to cover all three cases?

I've edited the documentation page to say it is about the path to public, private and temporary directories - please see https://www.drupal.org/docs/installing-drupal/some-directory-not-fully-p... and review.

Since the title is changed, the patch has been rerolled to reflect that.

Having an .htaccess file won't help you if you're using nginx, or any other web server out there. This assumes Apache currently... Hmmm.

Updated issue summary to reflect status.

@RobLoach There is another issue about handling this on non-Apache: #3117665: Only show the error “Public files directory Not fully protected” for Apache servers

The current plan is to remove the warning. Not sure if that the best approach, but I'm an Apache-user. It should be sorted out by those using nginx, etc.

+++ b/core/modules/system/system.install
@@ -604,16 +604,17 @@ function system_requirements($phase) {
-          'description' => t('See <a href=":url">@url</a> for information about the recommended .htaccess file which should be added to the %directory directory to help protect against arbitrary code execution.', [':url' => $url, '@url' => $url, '%directory' => $protected_dir->getPath()]),
+            'description' => t('See <a href=":doc">@doc</a> for information about the recommended .htaccess file which should be added to the %directory directory to help protect against arbitrary code execution.', [':doc' => 'https://www.drupal.org/docs/installing-drupal/some-directory-not-fully-protected', '@doc' => t('this documentation page'), '%directory' => $service->getTempDirectory()]),

* we've got a weird additional indent here
* let's just inline @doc into the translation string so the additional context is there for translators
* we're still hard-coding ::getTempDirectory for %directory, but we're in a loop at this point which is evaluating whether or not the .htaccess is in more than one place. Can we use the directory from the loop instead?

There's a string change here so this can only go into a minor.

Tagging for translators

Testing on D 9.5.7. ....

1. Error message leads to the wrong docs and finding this issue is a question of luck. Found it by checking if it already exist or needs to be created and then by finding a link in another issue leading to here.
2. After reading thru the issue it creates the impression the correct doc link is this: https://www.drupal.org/docs/installing-drupal/some-directory-not-fully-p...
3. This doc page states that removing a possible outdated .htaccess file will make Drupal to recreate it after entering the file management settings page in admin area. This is partly true and only happens if you run cron.
4. The .htaccess file created by Drupal after that will cause the same error message again. So still not save yet? Warning level in reports is high.

Comparing the created .htaccess file with other .htaccess which do not throw errors yet, shows following difference:

git diff --git a/private-files/.htaccess b/web/sites/default/files/.htaccess
index d436879..e7f06ca 100644
--- a/private-files/.htaccess
+++ b/web/sites/default/files/.htaccess
@@ -1,13 +1,3 @@
-# Deny all requests from Apache 2.4+.
-<IfModule mod_authz_core.c>
-  Require all denied
-</IfModule>
-
-# Deny all requests from Apache 2.0-2.2.
-<IfModule !mod_authz_core.c>
-  Deny from all
-</IfModule>
-
 # Turn off all options we don't need.
 Options -Indexes -ExecCGI -Includes -MultiViews

@@ -19,9 +9,9 @@ SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
 </Files>

 # If we know how to do it safely, disable the PHP engine entirely.
-<IfModule mod_php7.c>
+<IfModule mod_php5.c>
   php_flag engine off
 </IfModule>
-<IfModule mod_php.c>
+<IfModule mod_php7.c>
   php_flag engine off
 </IfModule>
\ No newline at end of file

Which all propably needs another issue since this here is only regarding the error message doc link. It also needs to be reported there then that different server enviroments handle mod_php different. The version of mod_php(x) used can have no number if default or can have a number even if still default. (mod_php vs mod_php7) - It also depends on if the server has multiple php versions available which can be switched via update-alternatives and similar tools (useful to have old Drupal projects running not supporting php 8 yet).

Since this is a security warning I partly agree on the issue status since this issue let users run in circles with no avail. I strongly recommend to add a temporary section to the docs linked to in the warning leading to here. The warning level in the admin reports is high so it isn't just a "notification".

In comment #29, diqidoq objects:

This doc page states that removing a possible outdated .htaccess file will make Drupal to recreate it after entering the file management settings page in admin area. This is partly true and only happens if you run cron.

This is not my experience. I've tested it and found that:

If the directory in question is writeable by the web server, the .htaccess don't already exists, the correct one is created automatically when the site administrator visits the file system configuration page.

This is really bad UX folks. Please see this support forum post for a recent example.

Setting it back to "Needs review". If you really think it "Needs work, please list remaining tasks in the issue summary.

A core committer commented with desired changes in #27 yet I don't see any patches since that, nor comments addressing those points.

Updated issue summary with current status.

#33 mentioned the changes that should be addressed

#33 doesn't mention any changes, it just refererences #27. As for #27, it mentions three changes, summarized below:

1. we've got a weird additional indent here
2. let's just inline @doc into the translation string so the additional context is there for translators
3. can we use the directory from the loop instead of ::getTempDirectory for %directory?

I've no idea what is meant by the first one, so I am unable to address this.

However, items #2 and #3 look sensible.

Anyway, in the meantime, development has moved from Drupal 9 to Drupal 11, and patch in #23 no longer applies.

Convert to an MR, and made changes. I hope they are useful. Also trying for a better commit message.

Opened the MR and pipeline is green.

Left 1 comment but not sure enough to warrant holding the ticket.

From what I can tell issues from #27 have been addressed, don't miss code reviews via comments at all.

Added some questions/comments.

I updated the doc page and the displayed message.

Believe feedback from @longwave has been addressed here. Also seeing the same as the screenshots provided.

Because of prevailing merge error.