Securing files on local storage only works on Apache [#1965028]

I can create a Storage container on the local file system and say that I want access control. Storage_api then places a suitable .htaccess file in the folder where those files are stored. I'm running nginx though, so storage_api silently fails to secure access to these files.

Without htaccess, the available mechanisms are to use a folder outside of the web root, or to not protect the files, but warn the user that they will need to use an alternative mechanism (eg in the nginx config). The warning could be either at the time the storage container is set up, or (better) directly tested so that it can be raised as an issue in the status report.

Comments

Comment #1

jbrown CreditAttribution: jbrown commented 9 April 2013 at 00:50

You are correct. What options does nginx have for this?

Comment #2

mc0e CreditAttribution: mc0e commented 15 April 2013 at 14:29

Nginx doesn't have anything equivalent to .htaccess. There's no good way to delegate authority such that drupal can write policy.

Come to that the Apache servers I've worked on have generally not allowed such delegation either, as it opens up a lot of security issues. I'd usually expect to disable htaccess mechanisms in any folder which the web server process can write to. Delegating from root to the web site owner or editors is one thing, but delegating to the web server process is not something I'd usually do. Which is not to say that it doesn't offer usability to people who want to make the tradeoff that way.

As I see it there are two good options, which are not mutually exclusive.

1. You can test whether the htaccess file (or another mechanism) is in fact securing the files, raise an alert if it's insecure, and leave it to the site owner or system administrator to sort out an appropriate response. I imagine this hooking into the site status report. You're not solving the security problem if it exists, but you're avoiding giving a false sense of security if there is a problem, and giving the site owner the chance to fix it. You could have your warning give a link to discussion of the issues and options if you wanted.

2. You can allow for and/or encourage use of a file directory outside the web root, readable and writable by drupal, but not directly addressable by URL. I suspect having a token expansion for inserting the current site name into the path might ease arrangements involving separate dev, production and staging environments.

Comment #3

Perignon CreditAttribution: Perignon commented 21 November 2014 at 11:10

Issue summary:	View changes
Status:	Active	» Fixed

We have a change in the code from the way this module creates htaccess files. It was actually a security patch that came out just a few months ago. Can you please re-test and see if this is still and issue? If it is, please reopen this ticket.