@xrow opened this Issue on October 25th 2016

Hi,

we had been working with piwik for some time now and we always had issues with permissions. We solved it by having the cron and webtraffic on different servers.

I was looking lately at this line. It seems that 750 seem too restricted by default since cron and webserver user need to write into the tmp dir.

https://github.com/piwik/piwik/blob/3.x-dev/core/Filesystem.php#L450

My proposal is to change to 0770. So that group apache/webserver can write too. That group is also the group of the cron user. I would hope/assume that would be also be a valid setup.

Other then that I am not sure how i can solve the issues that webserver and cron are different users.

@xrow commented on October 27th 2016

This change fixes our problems.

sed -i 's/075/077/' core/Filesystem.php
sed -i 's/075/077/' vendor/piwik/cache/src/Backend/File.php

The the feature request would be to make default permissions configureable:

600 as default for files can be changed to 660.
700 as default for directories can be changed to 770.

@tsteur commented on October 31st 2016 Member

I think it may be good to have a config setting for this. Background: For some users it is a problem to set permissions by default to 755 or 775. For other users it needs to be 777. So maybe we can quickly introduce a new config for this. Like file_allow_world_writable_permissions

@tsteur commented on October 31st 2016 Member

@xrow I'm not sure whether you are familiar with patching files. I have issued a PR for this here: https://github.com/piwik/piwik/pull/10812/files could you try to apply the changes to your server and then set the config entry allow_world_writable_file_permissions to 1?

I cannot promise that this PR would be merged as it is not really good to have 777 file permissions but it may be merged

@xrow commented on October 31st 2016

Hi @tsteur,

I checked the PR. That PR goes into the right direction, but is not ok since 777 should be avoided. https://github.com/piwik/piwik/pull/10812 maybe would solve our issue, but is not ideal.

I would try test a final PR, but https://github.com/piwik/piwik/pull/10812 is not ready.

@tsteur commented on October 31st 2016 Member

You are totally right. I think the problem is actually that we do not try 0775 here: https://github.com/piwik/piwik/blob/2.17.0/core/Filesystem.php#L494 similar to https://github.com/piwik/piwik/blob/2.17.0/core/Filesystem.php#L93 . This might be actually a "bug"

@xrow commented on November 1st 2016

In other system I know they try to solve it by making the mask configurable for directories and files. For my scenario I would need 770 and 660 as mentioned. Is it a good idea to implement this as a feature?

@mattab commented on November 3rd 2016 Member

In other system I know they try to solve it by making the mask configurable for directories and files.

it may be a good idea to solve it with configurable mask.
Do you maybe have example of how other system do this, and document it?

@xrow commented on November 3rd 2016

Hi,

this is quite straight forward and simple. Have a look.

https://github.com/ezsystems/ezpublish-legacy/blob/master/settings/site.ini#L970

Again... You need one mask for directories and one mask for files.

@lafrech commented on March 2nd 2017

I just experienced files/directories ownership issues and if think my use case might be related to this discussion.

Rather than using FTP, I manage web files using ssh, therefore with my own user id. Since I need files to be readable/writable by both my user and www-data, I created a dedicated group. All files/directories belong to that group, thanks to the SUID bit on the parent directory.

When piwik writes files/directories, however (session files, software updates), it does not give group write privilege, so my user can't modify / delete them.

In other words, once the parent dir is configured with the SUID bit, my user can install and run piwik without root privileges, but at some point, it can get locked out and need root privileges to delete piwik.

Maybe I shouldn't be doing this in the first place. I didn't find any alternative. Please excuse me if this is irrelevant.

@NathanQ commented on August 23rd 2019

@lafrech This is a relevant question and has become an issue when updating. Fetching new files creates them as one user, but the webserver is another. Is it assumed the webserver and the either zip downloader or git user will be the same and it's ok the webserver can access everything?

Powered by GitHub Issue Mirror