CiviCRM 4.4.4 "The CiviCRM debug log should not be downloadable."

[Mark Tompsett]

Having upgraded to CiviCRM 4.4.4 I get a warning message and this link...
http://wiki.civicrm.org/confluence/display/CRMDOC/checkUploadsAreNotAccessible
...but all I am seeing from that link is "TODO: checkUploadsAreNotAccessible"

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?
Can someone suggest a suitable such file, please?

Thanks
Mark

[Kurund Jalmi]

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

[clarkac]

I have .htaccess files with the contents as above, in both the directory mentioned and also in the upload directory. Yet I still get these two new warnings every time a user logs on.  I guess I've not understood what needs to be done here...  Can someone please help with this?

[totten]

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:

Code: [Select]

<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:

Code: [Select]

'/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):

Code: [Select]

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

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

Code: [Select]

'/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)


[Mark Tompsett]

Thanks for the feedback.

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?

Mark

[Mark Tompsett]

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   

[clarkac]

I just set permission on those 2 directories to 750 and guess what? It didn't make a happorth of difference! I tried 700 as well. Permissions does seem like an obvious fix...  I've asked my hosting company to look at this problem, so when I get it fixed I'll post the answer.  By the way, I installed 4.44 on an install at a different hosting site, and I have no messages there at all - the empty index.html file that Civi creates must have done the trick.  So the problem varies according to the host setup.

[Mark Tompsett]

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

Mark

[clarkac]

Yes, and an .htaccess file.

[totten]

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.

[clarkac]

I'm making no progress with this 
I checked with my hosting company & the .htaccess is supported.  I have placed a test file in both folders and tried to access them in a browser and they cannot be found - good?  But I still get the 2 error messages when I sign on.

I have compared this 4.44 install with a 4.44 I upgraded at a different hosting company (where I get no messages) and they are the same, except that in the problem install this is a second domain at the same site - so there's a folder public_html/acivi.org.uk which is where the domain folders are.  File structures and permissions are exactly the same in both installs, and all the civicrm settings are effectively the same.

[clarkac]

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? 

[Chris Burgess]

I've updated the docs on that Wiki page - http://wiki.civicrm.org/confluence/display/CRMDOC/checkUploadsAreNotAccessible

totten, please review and improve if you can?

clarkac, I'm not sure whether you're seeing false positives (=a bug in the check) or whether your server is legitimately warning you about direct access. Please attempt to follow the instructions in that doc and see if you believe you are being warned when the files in your uploads dir are NOT accessible. If so, please file an issue @ http://issues.civicrm.org (or give full details here if that's more accessible to you).

The check was introduced to reduce the number of sites that might "leak" personal data. I hope it's working correctly, but I feel your pain here.

You say "all users are seeing this warning" - AFAIK this should only be shown when the user has "administer CiviCRM" permission - do your users all have this permission?

[Chris Burgess]

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!

[clarkac]

Thanks for the update, Chris.  You are right about users who cannot administrate CiviCRM - they don't get this message. Sorry about that - I give my users this capability so they can manipulate tags.  At least this is good news.

My hosting company has confirmed that .htaccess at the folder level is fully supported, so I am stumped as to why I get this problem on one hosting site and not another.  And I don't know enough Linux to be able to sort it out, unfortunately.   I will look at raising this as an issue, but it's not consistent which is always tricky.

...and I hope you got your flight ok