New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error private directories are accessible #18132
Comments
If I run ./console diagnostics:run I get "Unable to test if mod_pagespeed is enabled: the request to http://unknown/./console?module" what seems to be a known bug since 2017. No idea how to solve this. |
@alexhass the mod_pagespeed log can be ignored in this case. You might just want to manually check if mod_pagespeed is enabled or not. If I understand correctly then some of the URLs are accessible via the browser, but they should NOT be. Which web browser are you using? See also https://matomo.org/faq/troubleshooting/how-do-i-fix-the-error-private-directories-are-accessible/ |
I habe an apache2 machine on debian9. I used the linked article to fix the issue, but it seems not working. Htaccess is allowed to change all settings. I guess your permission files are not working well. |
Hi @alexhass we haven't had any problems there otherwise in the past and it seems to work in general. Can you check
|
Same here. I use Matomo within Docker and the If I try to access these paths with my browser I get an 403. Why does the security check doesn't recognize the 403 status code? |
Never mind. |
Thanks for identifying the root cause. My install is also in a subdir. So I guess it is just a false alarm for now. |
Thanks for confirming @alexhass There must be something wrong with the method for the URL maybe as I'm just seeing it's actually supposed to include the path, but it doesn't seem to be the case in https://github.com/matomo-org/matomo/blob/4.6.0-b3/core/SettingsPiwik.php#L193 I guess once #18306 is fixed, this issue might be fixed too. Or the other way around. |
I unsuccessfully tried to recreate this issue using a fresh install of Matomo 4.5.0 in a subdirectory with Apache2.4 on Debian 10. The config directory .htaccess file is read and any browser attempts to access /matomo/config/config.ini.php are blocked with a 403 error. The system check calls the getCurrentUrlWIthoutFilename() method and it returns the URL with the correct subdirectory each time, therefore the publicly accessible directory check passes successfully. I did notice that if PHP-FPM is used then the .htaccess file will be ignored as .php files will be passed to the proxy and not handled by Apache. This did result in the publicly accessible directory system check failing. |
@bx80 could you maybe check the code if you find any reason why this wouldn't work? Or ask the two reporters some questions about their set up that might help why this isn't working? @alexhass @54mu3l are you running the system check through the console or the UI? Is there anything special about your setup? Maybe there's a proxy involved or something? |
I'm running the system check through the UI. Here a some more information about my setup: For Matomo I'm using the official Matomo image. A separate nginx image works as a proxy:
config.ini.php
I hope this helps. |
Thanks @54mu3l that is very helpful, I didn't configure a reverse proxy when trying to recreate this issue, so it could be that it's a combination of installing in a directory and using a reverse proxy that causes the problem. I'll take a look at issue #17945 first as it might offer insight into this issue. |
I’m not using a reverse proxy, but apache with php-fpm. |
@alexhass Thanks for the extra information, it sounds like the issue you are experiencing could be caused by PHP-FPM bypassing the .htaccess rules that are meant to prevent browser access to the /config directory. I use PHP-FPM too and have the same failed check. When Apache proxies PHP files to PHP-FPM the .htaccess file rules are ignored, so the expected One workaround is to add an additional proxy pass rule to your Apache config to prevent access to the config directory, this can be done by adding
This rule will achieve the same effect as the ignored .htaccess rules and the required private directories should then pass. It would be better we could handle this without the need to manually add extra rules to the web server config. @tsteur Do you think it is worth enhancing the 'required private directories' system check to detect if PHP-FPM is being used and then either... |
We would need to adjust https://matomo.org/faq/troubleshooting/how-do-i-fix-the-error-private-directories-are-accessible/ and mention php-fpm. I suppose we could try to detect php-fpm (if it's easy to do, but note that people also execute the diagnostic check on the command line so this might not be really possible). Not sure how easy it is to detect this? I think it might be good enough to mention in above FAQ to adjust php-fpm maybe. @Findus23 any thoughts? BTW could you reproduce so far the error that it is sending the request to the wrong URL mentioned in #18132 (comment) ? I was mostly keen on fixing this issue so we are requesting the right URL. |
Honestly I’m confused… my drupal installs have not shown any issues and I think the rules in apache all work and protect all files properly. I need to check that to compare to matomo. |
@alexhass Sorry for the confusion, I'm sure your Apache rules are fine. In this case Matomo is expecting one directory to be protected in a particular way, php-fpm changes this and causes the Matomo system check to fail. You can check if the config directory is protected by trying to load If you get a I hope that's some help. |
@tsteur It's fairly easy to detect if php-fpm is running for the current script with something like There seem to be two separate issues here, php-fpm bypassing .htaccess rules causing the private directories check to fail (this issue) and requesting the wrong URL with reverse proxies (addressed in #17945 - I managed to recreate that issue and have a suggested fix detailed there) |
I'm not familiar at all with how apache uses php-fpm, but I always assumed that it would work the same way as a regular nginx with php-fpm setup where all static files are served by the webserver and only requests to .php files (and in the case of Matomo-nginx only a subset of those) is forwarded to php-fpm. So I always assumed that php-fpm had no influence on .htaccess files therefore. But if this is the case, then we could detect php-fpm and fix a part of #13589 at the same time. |
@Findus32 That's correct, Apache only serves the static files and typically the proxy rules will send anything *.php to php-fpm. It's only when serving static files that Apache will check the .htaccess rules, but for anything passed to a proxy there is no check done by either Apache or php-fpm. So while php-fpm doesn't influence the .htaccess files themselves it does mean that they will be ignored when requesting .php files. (eg. requesting a non-php file from the config directory will return a 403, but a php file will be executed) The linked Matomo-nginx config with rules to exclude proxying php files from certain sensitive locations is the nginx equivalent of the Apache ProxyPass rule I mentioned above. Seems like it would be good to have both scenarios detected and provide information on recommended server configurations. |
fyi: I just updated my system to 4.7.1 and I still get the same error! The system check page still shows the following urls (without the sub directory):
Instead I would expect something like this:
|
Same here with PHP-FPM. Aside of this Debian 9 has no ProxyPassMatch rule set. The config looks like this only:
|
Hi @alexhass,
|
Hi @54mu3l, |
Ok it works now! I just needed to add Thanks everyone! |
That is too general. That could affect other applications on the server, too. |
Yes, that's just a generic example. If there are other applications being hosted under the same configuration then the rule would need to be adjusted to take that into account. 🙂 |
Don't use <LocationMatch "^/+(config|tmp|core|lang)(/.*)?$">
Require all denied
</LocationMatch> |
The security check fails, but security files have been generated.
./console core:create-security-files
Expected Behavior
No errors
Current Behavior
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.
Possible Solution
Fix bug.
Steps to Reproduce (for Bugs)
Context
None
Your Environment
The text was updated successfully, but these errors were encountered: