CiviCRM Community Forums (archive)

I am assuming that I need to put a .htaccess file in a directory such as mysite/sites/default/files/civicrm/ConfigAndLog/
Is that correct?

Yes

Can someone suggest a suitable such file, please?

You can create .htaccess file with following contents:

<Files "*">
  Order allow,deny
  Deny from all
</Files>

HTh
Kurund

It sounds like your web server doesn't support configuring access controls via .htaccess.

The next best option is to update the main configuration file for the web server. Unfortunately, the exact codes depend on your particular configuration, but here are a couple examples.

If the web server is Apache and the full path for the data folder is "/var/www/sites/default/files/civicrm/ConfigAndLog", then you could add this to the Apache configuration:

<Directory /var/www/sites/default/files/civicrm/ConfigAndLog>
  Order allow,deny
  Deny from all
</Directory>

The location of the Apache configuration file varies. Some common locations are:

'/etc/apache2/apache2.conf'; // Debian
'/etc/apache2/conf.d'; // Debian
'/etc/apache2/sites-available'; // Debian
'/etc/apache2/httpd.conf'; // OS X
'/etc/httpd/conf/httpd.conf'; // RedHat (Googled, untested)
'/opt/local/apache2/conf/httpd.conf'; // MacPorts (Googled, untested)
'/Applications/MAMP/conf/apache/httpd.conf'; // MAMP
'/Applications/XAMPP/etc/httpd.conf'; // XAMPP OS X (Googled, untested)
'/usr/local/etc/apache2x/httpd.conf'; // FreeBSD (Googled, untested)
'/usr/local/etc/apache22/httpd.conf'; // FreeBSD (Googled, untested)

If the web server is nginx, then you might add a configuration like this (untested - b/c I don't have nginx installed):

  location ~ ^/sites/.*/files/civicrm/(ConfigAndLog|upload|templates_c) {
    deny all;
  }

The location of nginx configuration file again varies, but some common locations are:

'/etc/nginx/nginx.conf'; // Debian, RedHat
'/etc/nginx/sites-available'; // Debian
'/opt/local/etc/nginx/nginx.conf'; // MacPorts (Googled, untested)
'/usr/local/etc/nginx/nginx.conf '; // FreeBSD (Googled, untested)


It is worth saying that having set these access permissions on these two directories that the two warnings about allowing access (that appeared in the Administer CiviCRM screen) stopped appearing, so that seemed to do the trick.

Hope that helps.
Mark   

So have you tried putting an empty index.html file in each of those directories for your existing installation?

Mark

Regarding changing file-level permissions as a fix: in a typical, "out-of-the-box", default configuration of most Linux distributions, changing the file permissions may strictly fix the security issue (and hide the warning) but break other things. The behavior that these directories should exhibit:

 1. Remote web users cannot read from the directory (configAndLogDir, templateCompileDir, and uploadDir)
 2. Remote web users can read from the directory - but cannot browse a listing (imageUploadDir)
    (This is actually the easiest requirement to solve, and Civi 4.4.4 has a built-in solution -- creating blank index.html files.)
 3. The local PHP process can write to the directories (configAndLogDir, templateCompileDir, and uploadDir plus imageUploadDir)
 4. The local PHP process can read from the directories (configAndLogDir, templateCompileDir, and uploadDir plus imageUploadDir)
 5. The local PHP process can execute code from one of the directories (templateCompileDir)

In most default configurations, PHP and httpd run with the same credentials (eg POSIX user "www-data", "www", "httpd", or "apache" -- for brevity, I'll refer to user "www-data" going forward). Now suppose we use filesystem permissions to deny "www-data" access to "configAndLogDir". This has the desired effect of stopping httpd from reading the directory (and thus blocking remote web users). But it also has the undesired side-effect of stopping local PHP processes from reading/wrting configAndLogDir. Thus, the PHP process can't write to the log! (Or if PHP can't read/write templateCompileDir, then you'll eventually have problems with rendering output. Or if PHP can't read/write the uploadDir, then you won't be able to import CSVs, etc.)

If we move away from default configurations and start looking at more advanced security techniques (which are more common in shared hosting and less common in dedicated hosting), then things can get quite different -- it is *possible* that manipulating file-permissions will do the job. But there are too many possible configurations and not enough standards. We'd have to write a small book to account for them all. This is why we've provided an audit tool rather than a canned solution -- we can easily detect the problem, but the solution depends on the particulars of the hosting environment.

---

One point that I should have highlighted earlier. For configAndLogDir, templateCompileDir, and uploadDir, there's another solution which doesn't involve reconfiguring httpd -- move the directory somewhere else (somewhere outside the web root). You'll need to update civicrm.settings.php and "Administer CiviCRM => System Settings => Directories" for that to happen.

This is getting worse - was this ever tested on more than one installation?
I moved  ConfigAndLogDir outside webroot as suggested, and that seems to break other things.  I now get messages about 'Error loading module file () Please restore the file or disable the module' (nearly all the time) and also ''CiviCRM Extensions Directory' directory does not exist'   Thanks goodness this is only a test system!

For me, 4.44 is a dead duck - I am an implementer, not a Linux guru.  How on earth am I supposed to get this working?  Contrary to the documentation, regular users get these messages not just administrators (depending on what you mean by administrators).  Is there some way that I can choose to accept the risk of these folders being readable and suppress these messages?  Especially since they don't seem to be readable anyway...  And get on with 4.44? 

What I actually did was to change the file permissions on the two directories concerned as per this screenshot...
This means that the permissions are set such that User and Group can Read but World cannot.
It also means that only User can Write.
Actually I set it so that User and Group could Execute but World could not, so the Permissions are actually 0750 (not 0751).

Would that accomplish the same thing as setting a .htaccess file?

No. If your permissions changes prevent the webserver accessing the file, CiviCRM may not function correctly. Files here need to be accessible locally (= to CiviCRM scripts when executing) but not retrievable over the internet (= your browser).

For me, 4.44 is a dead duck - I am an implementer, not a Linux guru.  How on earth am I supposed to get this working?  Contrary to the documentation, regular users get these messages not just administrators (depending on what you mean by administrators).  Is there some way that I can choose to accept the risk of these folders being readable and suppress these messages?  Especially since they don't seem to be readable anyway...  And get on with 4.44? 

Yes, it's possible to configure settings so that it doesn't warn you. Hopefully someone else can help with this - my plane is boarding now!