Today, I upgraded to Matomo 4.3.0. The Matomo system check complains about "Required Private Directories". Specifically, it tells me:
"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.
We also found that Matomo's config directory is publicly accessible. While attackers can't read the config now, if your webserver stops executing PHP files for some reason, your MySQL credentials and other information will be available to anyone. Please check your webserver config and deny access to this directory. "
I'm not positive, but something seems to be messed up here. I have my config directory set to 700. My config.ini.php is set to 600. What should the permissions be? Matomo doesn't say what it is looking for. For me to lock it down further, I basically have to change take access away from the Apache user. Maybe I'm missing something obvious, but this doesn't seem right.
Maybe some documentation somewhere should be updated... And a link to this doc should be provided in the warning message?
At least on my server
config/config.ini.php returns a single ';'
tmp/cache/tracker/matomocache_general.php returns an empty file
causing the check to complain since something is returned.
Also to me it seems those files exist by default, how are they supposed to be protected? (The warning should tell you too ..)
I have explained this a bit more detailed here:
Maybe the error message could be expanded with this help
I'm using centos7 and httpd, the .htaccess is there but doesn't seem to work for me.
I'm investigating possible reasons, the use of php-fpm being one candidate ...
One thing: With the current check Matomo doesn't accept it, if the config.ini.php returns a 304 e.g. to the homepage.
I'm open to other suggestions on the best way to fix this. However, I have placed this in my Matomo Apache configuration:
<LocationMatch "^/(tmp|config|lang)"> Require all denied Require ip 127.0.0.1 </LocationMatch>
And this has removed the warning from the Matomo system check. Again, I'm open to suggestions of a better way to address this.
I think initially there was a check for the retrieved content. To adjust the check for redirects etc maybe we could follow redirects and check if the retrieved config is
trim($content) !== ';' (before was only a contains check or so) and check whether it's actually returning any content from the config. So if response code is >=400 && < 500 then all is good. If not we'd maybe do some additional checks regarding the redirects etc (we need to follow the redirects to see if it maybe just redirects from http to https etc)
Hi guys, I've also had this problem after updating to 4.3.0, but for a different file and folder. For my site, the "Required Private Directory" warning refers to this URL:
My site is running on Apache, and inside my /lang/ directory there is a Matomo-generated .htaccess file which I've attached to my comment here (renamed to a .txt file). As far as I can tell, it's configured correctly to block all the files in this directory.
However, when I check the HTTP response header of the above URL, it's returning "200 OK", rather than 4xx.
Any idea why? To me it feels like Matomo is doing something wrong here.
I was in the process of manual installation of Matomo 4.3.0 on Centos 6.9 with PHP 7.2.24, MYSQL 5.5, Apache 2.2.
However I face the same issue as mentioned above on the following file i.e :
i.e the following error is thrown after visiting Diagnostic->System Check :
Could you please replicate and fix the issue?.
Created https://github.com/matomo-org/matomo/pull/17604 as a first improvement as well as this FAQ https://matomo.org/faq/troubleshooting/how-do-i-fix-the-error-private-directories-are-accessible/ which we can improve and complete over time.
To fully fix this issue we should maybe split the detections into two parts:
lang/en.jsoncheck for now). Once we add more checks eg for
coreetc then we could move these files in there as well.
/tmp is also hard coded and we may want to use
StaticContainer::get('path.tmp') instead. And in case that
strpos($tmpDir, PIWIK_INCLUDE_PATH) === false then we would need to assume the tmp is not in the public directory and don't need to execute the check for the tmp directory.