Hi,

The matomo opensuse package is not maintained by the matomo team so any issue that's in it should be reported to the maintainers.

I also am not sure I understand your point correctly:
If I create a symlink from testfile -> /etc/shadow and tell root to run sudo chown someuser:someuser testfile that doesn't mean that I make /etc/shadow readable to someuser.

Can you please expand on what exactly is the issue and on how to repoduce it in a normal Matomo installation.

If I create a symlink from testfile -> /etc/shadow and tell root to run sudo chown someuser:someuser testfile that doesn't mean that I make /etc/shadow readable to someuser.

actually you do, if you first set the sysctl fs.protected_hardlinks to 0...

also: the suggestion to run a chown -R does come from matomo. just run a chown -R root:root on the matomo install folder and you'll see it for yourself next time you tr to use matomo.

actually you do, if you first set the sysctl fs.protected_hardlinks to 0...

I fail to see why this is an Matomo issue. If the system you install Matomo on is using kernel settings which lowers security outside of "best practice", thats not an issue for Matomo to handle. This would be an issue for any web app then, but it is not.

that still does not change the fact that you (as in, the people working on matomo) are suggesting file system permissions that are way too open. only tmp inside the matomo installation folder needs to be owned by the apache user, not the whole install.

only tmp inside the matomo installation folder needs to be owned by the apache user, not the whole install.

If you want to use the GeoIP2-Updater or upload a custom logo /misc also needs to be writable, if you want to use the plugin marketplace plugins needs to be writable and if you want to use the updater everything needs to be writable.

I'm installing matomo through a RPM package, so I definitely am not going to use the updater... the other two folders I can understand and put in the spec file for the RPM package.

Most webapps need full access to their installation path. I do not see a higher than usual risk in the case of Matomo.

If this is a specific problem with the RPM-package, as you mentioned, this is the wrong issuetracker for this.

guys, I am one of the guys who is working on the RPM package, and what I'm doing here is reporting a problem upstream.

Most webapps need full access to their installation path. I do not see a higher than usual risk in the case of Matomo.

Most webapps that i know only need write access to very specific folders that should at best be kept outside the installation path but I understand how that can't be done for at least the plugin path.

As @Findus23 already mentioned:

If you want to use a autoupdater, everything needs to be writable by the webserver. I understand that that is not the case with the RPM package. But it needs to be changed in the RPM package than and not in upstream.

I am changing it in the RPM package. I thought you people might be interested in the fact that there's a local prvivilege execution issue with that approach. But from this it looks as if you don't care.

thinking about it some more, how about the RPM package includes a patch that disables the auto updater, and gives the user an appropriate text instead... something like this:

"Matomo version x.y.z has been released, but this installation has been installed through your system's package management, Please inform your system administrator about the update."

Could you guys point me at the right php file to do that?

ok I found enable_auto_update in global.ini.php, that should do it.

Thanks for the feedback, makes sense 👍
We will close this as for us, having auto updater work is important, so we won't change the messages for now.