Required Private Directories System Check - Improve Documentation

[dev-101]

Ok, found this after upgrade to 4.7.0 but I am not sure, maybe it was also there during 4.6.x or 4.5.x or older cycles, I wasn't checking really.

I have 2 shared plans, both running Piwik/Matomo like this:

HOSTING A / SITE A runs since 2015 or so, originally a Piwik installation, later updated to Matomo Server: Litespeed PHP SAPI: litespeed

This is the one which has the following error in System Check:

Required Private Directories | https:// ... /piwik/tmp/cache/tracker/matomocache_general.php

We found that the above URLs are accessible via the browser, but they should NOT be. Allowing them to be accessed can pose a potential security risk since the contents can provide information about your server and potentially your users. Please restrict access to them.

What happens when I access that private dir's URL? It returns my website's home page and HTTP 200 OK response.

HOSTING B / SITE B runs since 2020 or so, originally a Matomo installation (say 4.x branch that was actual back then) Server: Litespeed PHP SAPI: apache2handler (hosting fixed this to litespeed now, doesn't affect this issue)

This one does not have a security report problem as the one above, and with kind support from my hosting, we tracked that this line in root .htaccess file is actually responsible for 403 Forbidden message to cache URL:

# Matomo Security
# Deny access to cache sub directory
RewriteRule ^matomo/tmp/cache/tracker/.*\.(php|js|rb|py)$ - [F,L,NC]

Checking ownerships and permissions, here's the interesting part: /tracker/ folder is 0700 on B hosting site/server, and it was 0750 on A hosting/site. Inside newer site B there are .php files (0664) and generated cache files (0600). In site A there are only .php files (0664), no cache files are created (assuming because Matomo check fails, for security reasons). I fixed 0750 manually with 0700, but this didn't resolve the issue.

Then I added the missing line from public_html folder's .htaccess file on plan A:

# Matomo Security
# Deny access to cache sub directory
RewriteRule ^piwik/tmp/cache/tracker/.*\.(php|js|rb|py)$ - [F,L,NC]

Important: replace matomo dir name with your actual name e.g. piwik or whatever.

And this actually fixed the security issue. I think, judging by the position of this rule on site B in .htaccess file (near the top, but not exactly first lines) is that I added them at some point in the past.

Now, why I wrote this mini-novel here? Well, maybe you should add it back in your documentation, as a possible solution or workaround.

It took me a whole day to figure this one out, and I am not really sure why it doesn't work on my sites without htaccess rules.

I tried .console commands fix, but that just didn't do anything, really.

Thanks

[bx80]

Hi @dev-101, thanks for raising this issue and taking the time to explain in detail :+1:

This system check is expecting an HTTP error code in the 4xx range, such as a 403 inaccessible or 404 not found when checking the private directories. Matomo will automatically create .htaccess files to block access to private directories, but not all web server configurations support these default rules and sometimes manual rules are required.

I think we need a new FAQ which explains in more detail the possible options to restrict access to private directories if this check fails and then show a link to the FAQ as part of the system check error message.

[tsteur]

FYI there is this FAQ: https://matomo.org/faq/troubleshooting/how-do-i-fix-the-error-private-directories-are-accessible/

Maybe there's a quick tweak we could do to make something more clear?

[dev-101]

This system check is expecting an HTTP error code in the 4xx range, such as a 403 inaccessible or 404 not found when checking the private directories. Matomo will automatically create .htaccess files to block access to private directories, but not all web server configurations support these default rules and sometimes manual rules are required.

That's the thing confused me in the begining, Matomo doesn't create local .htaccess here, which is weird (it should).

Then I tried copying .htaccess (which Matomo uses for /tmp/ dir 2 levels above) into /tracker/ dir, but it didn't work (didn't block anything):

# This file is auto generated by Matomo, do not edit directly
# Please report any issue or improvement directly to the Matomo team.

# First, deny access to all files in this directory
<Files "*">
<IfModule mod_version.c>
    <IfVersion < 2.4>
        Order Deny,Allow
        Deny from All
    </IfVersion>
    <IfVersion >= 2.4>
        Require all denied
    </IfVersion>
</IfModule>
<IfModule !mod_version.c>
    <IfModule !mod_authz_core.c>
        Order Deny,Allow
        Deny from All
    </IfModule>
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
</IfModule>
</Files>

I think we need a new FAQ which explains in more detail the possible options to restrict access to private directories if this check fails and then show a link to the FAQ as part of the system check error message.

Yes, definitely.

[bx80]

The .htaccess files that Matomo generates contain Apache file rules, although lightspeed supports rewrite rules in .htaccess files I'm not sure that it supports file rules.

Maybe we could improve the FAQ with some extra troubleshooting steps at the bottom?

• Check if the site configuration allows overrides (otherwise .htaccess files will be ignored)
• Suggest using a rewrite rule if not using Apache (with example)
• If using PHP-FPM a proxypass rule may be required (#18398)

Then add link from the system check error message to the FAQ.

It could help troubleshooting if the core:create-security-files command would check if the .htaccess files were successfully created and show an error message if they were not. At the moment it gives no indication if directory permissions prevented the files from being created.

[dev-101]

The .htaccess files that Matomo generates contain Apache file rules, although lightspeed supports rewrite rules in .htaccess files I'm not sure that it supports file rules.

Prepare for more weirdness: LiteSpeed apparently does support < files > directives, I just checked accessing URLs both to /tmp/ and /tmp/cache/ links, all returning 403 properly on both sites. So, why it didn't work when I manually copied it into /tracker/ dir I don't really know.